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1 

INTRODUCTION 


1.1 BACKGROUND 

This Preliminary Project Implementation Plan (PPIP) has been developed by 
General Dynamics as part of a NASA Phase A study examining the feasibility of 
replacing the current Solid rocket Boosters on the Space Shuttle with Liquid Rocket 
Boosters (LRBs). Plans such as this are typically prepared during the later phases of a 
project, but the PPIP is warranted in this case due to the need to determine the 
implications of integrating the LRB with the Space Transportation System at the earliest 
practical date. 


1.2 PURPOSE 

The ultimate purpose of the LRB Project Implementation Plan (PIP) will be to 
identify and define all elements required in a full scale development (FSD) program for 
the LRB. The purpose of this preliminary plan is to provide management level visibility 
of the FSD phase program as planned by the study contractor, to the extent possible 
during a Phase A study of a program of this complexity. Its submittal satisfies the Data 
Requirement (DR)-9 specified for this study. The PPIP will be updated periodically until 
the end of Phase B, when it will be formally approved by General Dynamics and NASA 
as the final Project Implementation Plan. From that time hence, it will serve as the 
principal reference guide for management of the LRB program, addressing such 
requirements as design and development, configuration management, performance 
measurement, manufacturing, product assurance and verification, launch operations, 
and mission operations support. 
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1.3 CURRENT SUBMITTAL 


This document is the initial submittal of a draft PPIP, delivered to the NASA 
Marshall Space Flight Center (MSFC) in May 1988. After NASA review and comment, 
an updated version of the PPIP will be submitted in July 1988 along with the final report 
of the Phase A study. 
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2 

PROJECT MANAGEMENT 


2.1 MANAGEMENT APPROACH 

General Dynamics' approach to the management of the Liquid Rocket Booster 
(LRB) program is aimed at achieving the principal objective of the program — 
enhancing the safety and performance of the Space Transportation System (STS) — at 
the lowest possible cost and with minimal disruption to STS operations. We feel there 
are three vital elements to accomplishing this goal: careful up-front planning, 
encouragement of communication at all levels of the organization, and use of the best 
available management support tools and technologies. 


2.1.1 PROJECT ORGANIZATION 

General Dynamics Space Systems Division (GDSS) was established in March 
1985 to improve the corporation's ability to effectively manage space programs. GDSS 
utilizes a matrix management system wherein programs such as LRB are staffed 
primarily by personnel with permanent reporting relationships to home functional 
departments, such as Engineering, Production, and Finance. Only the LRB program 
manager and certain members of his staff are likely to be permanent employees of the 
LRB program office. This arrangement enables programs such as LRB to make the 
most effective use of the personnel assigned to the program and permits employees on 
such programs to tap into the broader resources of their home functional departments 
as needed. 

Since this is a preliminary plan developed during Phase A of the LRB program, it 
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is too early to identify the specific personnel or reporting relationships that will be 
established for the full scale development phase of the project. If the program is 
managed within Space Systems Division, the program manager will in all likelihood 
report directly to the division general manager, who currently reports directly to the 
president of the corporation. An alternative option that will be considered during Phase 
B of the program will be to establish a separate division to implement the LRB program. 
In this case, the LRB program manager would be expected to report to the president of 
the corporation or one of the president's staff members. 

The LRB program manager will be supported by a deputy program manager and 
can be expected to have several key personnel reporting directly to his office. The staff 
positions that typically report directly to the manager of a project such as LRB include a 
chief engineer, a manufacturing manager, a colocated product assurance and safety 
representative, a program control manager, and an administrative officer. 

The LRB project will be organized according to the program Work Breakdown 
Structure (WBS). A preliminary WBS for the LRB program is shown in Figure 2-1. 
Each functional organization supporting the LRB program will be assigned 
responsibility for certain WBS elements, and will receive a separate budget for each 
WBS element that it must support. Each organization will further subdivide its tasks into 
discrete work packages that will receive specified portions of the organization's budget. 
The WBS will also align the working level interfaces between our LRB organization and 
the NASA project office responsible for managing the LRB project. 


2.1.2 PROCUREMENT 

It will be the LRB prime contractor’s responsibility to develop a Make/Buy Plan that 
best utilizes its capabilities and those of its subcontractors. This is vitally important for 
achieving a high quality product at the lowest possible cost. General Dynamics' many 
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WORK BREAKDOWN STRUCTURE INDEX 

FOR THE 

LIQUID ROCKET BOOSTER 


LEVE L WBS ELEMENT TITLE 

Total Project 

1 00-00-00 Liquid Rocket Booster Program 

Hardware Elements Dimension 


2 

3 

4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
3 

3 

4 
4 

3 

4 
4 
4 
4 

3 

4 
4 
4 

J 

3 

4 


01 - 00-00 

01 - 01-00 

01 - 01-01 

01 - 01-02 

01-01-03 

01-01-04 

01-01-05 

01-01-06 

01-01-07 

01-01-08 

01-01-09 

01 - 01-10 

01 - 02-00 

01-03-00 

01-03-01 

01-03-02 

01-04-00 

01-04-01 

01-04-02 

01-04-03 

01-04-04 

01-05-00 

01-05-01 

01-05-02 

01-05-03 

01-05-04 

01-06-00 

01-06-01 


Liquid Rocket Booster 

Structures & Mechanisms 
Oxidizer Tank 
Fuel Tank 
Intertank Adapter 
Forward Adapter 
Thrust Structure 
Aft Adapter 
Avionics Installation 
Launch Hardware 
Pressurization 
Nose Fairing 
Separation System 
Thermal Protection 
Tank 
Body 

Main Propulsion 

Expendable Engines 
Reusable Engines 
Propellant Feed System 
Engine Actuators 
Avionics 

Guidance, Navigation, & Control 
Instrumentation & Data 
Communication & Tracking 
Range Safety 
Electrical Power 

Power Distribution Unit 


Figure 2-1. LRB Work Breakdown Structure. 
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WORK BREAKDOWN STRUCTURE INDEX 

FOR THE 

LIQUID ROCKET BOOSTER 
LEVEL WB£ ELEMENT TITLE 

Hardware Elements Dimension fcont'd) 


01-06-02 

Cabling & Harness 

01-06-03 

Batteries 

01-07-00 

Recovery System 

02-00-00 

Orbiter 

02-01-00 

Avionics 

02-01-01 

Guidance, Navigation, & Control 

02-01-02 

Controls, Displays, & Instrumentation 

02-01-03 

Communications & Data 

02-01-04 

Data Management 

03-00-00 

External Tank 

03-01-00 

Flight Hardware 

04-00-00 

Facilities 

04-01-00 

Manufacturing 

04-02-00 

Test 

04-03-00 

Launch 

04-04-00 

Mission 

04-05-00 

Recovery 


Phase & Function Dimension 

1 000 Liquid Rocket Booster - Phase & Function ' 

1100 DDT&E 

1110 Program Management 

1120 Engineering 

1 1 21 Systems Engineering & Integration 

1 1 22 Design & Development 

1 1 30 Ground Support Equipment 

1140 Manufacturing 

1141 Initial Tooling 

1 1 42 Initial Spares 

1140 Test 

1141 Ground Test 

1142 Flight Test 

1 1 43 Test Operations 


Figure 2-1. LRB Work Breakdown Structure (Continued). 
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WORK BREAKDOWN STRUCTURE INDEX 

FOR THE 

LIQUID ROCKET BOOSTER 
LEVEL WS ELEMENT TITLE 

Phase & Function Dimension (cont’d) 


2 

1200 

Production 

3 

1210 

Program Management 

3 

1220 

Sustaining Engineering 

3 

1230 

Manufacturing 

4 

1231 

Sustaining Tooling 

4 

1232 

Flight Hardware 

4 

1233 

Final Assembly & Che 

2 

1300 

Operations 

3 

1310 

Operations Support 

4 

1311 

Program Support 

4 

1312 

Spares Procurement 

4 

1313 

Mission Control 

3 

1320 

Launch Support 

4 

1321 

Ground Operations 

4 

1322 

Propellant Operations 

4 

1323 

Other Operations 


Figure 2-1. LRB Work Breakdown Structure (Continued). 
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years of experience as prime contractor for the Atlas and Centaur programs will be 
drawn upon as required to rapidly develop an effective Make/Buy Plan. 

Recent corporate initiatives will enhance General Dynamics' ability to develop and 
implement a procurement strategy that helps meet the goals of the LRB program. As 
part of a corporate-wide program to improve the company's competitiveness, 
procurement policies have undergone a thorough review, with emphasis on renewing 
our commitment to obtain goods and services from our vendors and subcontractors at 
the lowest possible cost. More specifically, several major steps were taken by Space 
Systems Division in the 1987-88 time frame to improve its ability to make the most 
effective use of subcontractors in the production of launch vehicles. These included: 
establishment of the Commercial Atlas/Centaur program, implementation of an 
extensive factory modernization program, and the setting up of additional production 
facilities at remote locations to reduce the cost of acquiring certain launch vehicle 
components. 

To enhance the specific procurement practices of the LRB program, several steps 
will be taken. These will include: 

a. Identification of subcontractors and involvement of them in our activities as early 
in the program as practical. 

b. Establishment of innovative incentive programs to acquire LRB subsystems, 
components, and piece parts at the lowest possible cost. 

c. Establishment of state-of-the-art receiving and inventory control capabilities at 
the LRB final assembly site. 
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2.1 .3 PROJECT CONTROL 


Project control for the LRB program will be supported by General Dynamics' 
SIMS-II system, the cornerstone of our performance and cost reporting system. 
Installed in January 1987 to provide a basic management support tool, SIMS-II is a 
computerized system used at all levels to help organize and plan the scope of work. It 
provides information for planning, assessing task accomplishment, evaluating cost and 
schedule performance, analyzing trends, and projecting requirements. It is a well 
documented and proven management system for planning and controlling contractual 
tasks. It is the standardized management system applied to nearly all contracts at 
General Dynamics Space Systems Division and was validated by the U.S. Air Force as 
meeting all requirements of DODI 7000-2 on 15 July 1987. 

The application of SIMS-II to the LRB program will provide information necessary 
for preparation of any required NASA 533s as well as our own internal management 
reports. SIMS-II is fully compliant with program cost and schedule reporting 
requirements on other large NASA programs. It is documented in the directive 
manuals of the Space Systems Division and is subject to periodic examination by the 
General Dynamics Corporate Internal Audit function. These financial practices are 
performed with the approval and constant surveillance of in-plant government 
representatives. These agencies review Space Systems Division financial information 
for allowable costs under regulations of NASA and other government agencies. 

General Dynamics has evolved a financial management system based on 
utilization of the program Work Breakdown Structure (WBS). As explained in Section 
2.1.1, all activity on the LRB program will be oriented to the WBS to ensure integration 
of cost with tasks. Our SIMS-II accounting system will provide for accurate tracking of 
all direct and indirect costs applicable to the program. The cost accumulation (work 
order) structure will provide integration of WBS and cost tracking at any level of the 
WBS or functional organization. 
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The ten digit work order (AWO) numbers for a contract are developed in a logical 
sequence within the cost accumulation structure following the WBS structure. These 
AWOs are controlled by entry into a computerized master file only when authorized by 
a sales order. The four digit department number is used to identify the organization 
incurring the cost. 

Cost baseline budgeting is initally accomplished by planning the hours and 
non-labor cost elements through the period of performance. These are entered into the 
SIMS-II system and a dollarized time-phased budget document is produced. Work 
Authorization Plans (WAPs) are prepared to describe all tasks and are fed into the 
SIMS-II system. WAPs define task effort in hours by months and milestones which 
define task progress. Hours planned are partitioned into active and planning packages 
which support project planning. WAP tasks are at the functional group level and lowest 
WBS level for each task. 

All changes to the plan must be authorized by the GDSS program manager and 
conform to the authorized contract plan. Changes to budgets are made as 
modifications to the WAPs and entered into SIMS-II. As scheduled milestones are 
accomplished, the budgeted value is reflected as earned value. SIMS-II summarizes 
budget, earned value, actual cost, and forecast data from cost accounts through the 
WBS to produce totals at any required level. Our monthly Performance Measurement 
Report (PMR) provides comparative values for planned work performed, planned cost, 
and actual cost. The PMR also calculates variances to plan. 

The PMR and budget baseline reports are provided to each program on a monthly 
basis. This provides an early warning of potential problems. Use of the PMR allows 
these problems to be pinpointed as to WBS and functional department. 
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2.2 PROJECT SCHEDULES 


Since the objective of the LRB program is to enhance the performance and safety 
of a launch system that is already operational, timely implementation of the LRB 
program is particularly vital to its success. Using the SIMS II system described above, 
LRB program milestones can be achieved in a timely manner without compromising 
safety or performance. LRB schedules will be developed from contract requirement 
milestones progressively downward through all levels of the WBS. These will be 
directly related to the WBS task to provide realistic schedules for first-line work 
authorization documents. The schedule will reflect the major milestones as identified 
by NASA. Task accomplishment is keyed to the milestones where applicable. 


2.2.1 LRB MASTER SCHEDULE 

A preliminary LRB project master schedule is shown in Figure 2-2. Since a final 
selection between pump-fed and pressure-fed LRBs has not yet been made, this 
schedule shows engine development milestones for both concepts; development time 
required for the pressure-fed engine is about one year shorter. The schedule also 
illustrates General Dynamics' view that the LRB project should be implemented as 
rapidly as possible; we show a relatively short (one year) Phase B beginning in the 
second quarter of calendar year 1989, followed immediately by Phase C/D. This will 
require competition for LRB full scale development during the latter half of Phase B. 
This is an unusual approach for NASA programs, but has been used for Air Force 
space programs, most recently in the transition from Concept to Validation phases on 
the Advanced Launch System program. 
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2.2.2 LRB PROGRAM ELEMENT SCHEDULES 


Figures 2-3 through 2-6 show schedules for various LRB program elements. 
These schedules are all preliminary, as would be expected at this early phase, and will 
be updated as the program matures. 


2.3 RISK ASSESSMENT 

The key to successful risk management is awareness. Our three-point approach 
to minimizing risk impact consists of: 

a. Identification, through an engineering and management work force sensitive to 
the need for early recognition and reaction to potential problems. 

b. Avoidance where possible, through selection of proven approaches. Major 
trades related to risk are expected to be complete prior to initiation of full scale 
development. 

c. Managing, through comprehensive planning and review, with consideration for 
alternate (backup) approaches, and schedule or budget reserves. 

This general approach is common to all risk categories, though the specific techniques 
and tools may differ. 


2.3.1 TECHNICAL RISK 

At this time there are few major technical risks anticipated in LRB development. 
This is primarily because our program strategy is to minimize risk by utilizing existing, 
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Figures 2-3 Through 2-6. LRB Schedules (To be provided in final PPiP submittal). 
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proven technologies wherever possible. Potential areas in which risks might evolve 
include: 

a. Need for new technology development. Ablative engine cooling and welding 
processes for thick aluminum/lithium structures are examples of advanced 
technologies that could result in added technical risk. As such new technology needs 
are identified, we will develop specific plans to minimize the potential for program 
impacts. Drawing upon the expertise available in the country, our plans will evaluate 
and select approaches, quantify risks, and establish appropriate schedules, budgets, 
and review processes. 

b. Aerodynamic interaction effects. Wind tunnel tests prior to full-scale 
development should minimize potential impacts. The test techniques and aerodynamic 
data base established in Space Shuttle work to date add significant confidence that 
changes resulting from incorporating the LRB can be accomplished at low risk. 


2.3.2 SCHEDULE RISK 

Planning, aided by use of our computerized scheduling system, will be used to 
establish realistic schedules. Use of this scheduling system in conjunction with our 
Performance Measurement System will provide the insight to identify trends in time to 
take effective action. Critical path analyses will be performed to identify those tasks that 
are most critical to achieving program milestones. 

The most significant schedule risk is integration of the LRB into launch site 
operations. The launch pad and Vehicle Assembly Building (VAB), which will be in use 
for STS operational flights, will require modification for LRB compatibility. Tying up 
these facilities for LRB modifications could impact STS launch schedules. 
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Our approach to minimizing this risk is to emphasize the early definition of 
interface requirements to support those modifications. The maturity of the STS launch 
operation provides a good base against which we can develop firm requirements to be 
accommodated by the launch site facilities. In addition, we recommend that NASA 
consider the use of "modkits" to reduce facility down time, and early incorporation of the 
mods prior to the 1994-1995 time frame, when the STS flight rate is expected to peak. 
More detailed descriptions of launch site modifications required to support LRB are 
contained in Section 8 of this plan and Appendix A: SRM/LRB Transition Plan. 


2.3.3 COST RISK 

Cost risk occurs most often as a result of of poorly defined cost estimates, changes 
in requirements, or problems deriving from technical or schedule risks. Our approach 
to minimizing cost risk is to emphasize the development of accurate and realistic cost 
estimates from the earliest stages of the program onward. The maturity of the Space 
Shuttle program and our experience manufacturing and launching the Atlas booster 
(similar in many regards to the pump-fed LRB) provide a reasonably good basis for 
establishing sound cost estimates. We have already begun the process of calibrating 
our existing booster cost models by testing them against the NASA Shuttle cost models 
and actuals. 

The Space Shuttle provides a similarly valid base for development of LRB 
requirements, which is key to reducing the probability of incurring expensive design or 
procedural changes downstream. In concert with the LRB project goals of maintaining 
compatibility with the existing Shuttle flight vehicle and operations, we consider our 
requirements baseline to be much more firm than in the case of a new launch vehicle. 
The LRB program control manager responsible for cost performance will have authority 
to take all reasonable steps required to meet cost targets. Our experience on 
design-to-cost programs such as the Space Shuttle mid-fuselage and Space Station 
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will help ensure that we are organized effectively for the minimization of cost risk. This 
combination of proven estimating techniques and sound management controls will 
provide the basis for effective LRB cost control. 




3 

SYSTEMS ENGINEERING AND INTEGRATION 


3.1 APPROACH 

Integration responsibilities of the LRB prime contractor include definition and 
refinement of system requirements, development of compatible interface designs, 
support for the development of an integrated STS system verification program, and 
support for the development of launch site operations. The role of the systems 
integrator on this program is especially critical due to the LRB's integration into an 
existing manned launch system. GDSS will actively participate with the 
NASA/Marshaii Space Flight Center (MSFC), other NASA centers involved in the 
project, and the STS integration contractor to minimize requirements for STS 
modifications. 

The relationship of the General Dynamics LRB Project Office with the 
NASA/MSFC Project Office and the STS systems engineering and integration (SE&I) 
activity is shown in Figure 3-1. We recognize the importance of early identification and 
resolution of systems integration issues and will support the STS technical panels in 
this process. Such support will continue on an as-required basis through LRB flight 
testing. As part of this support we will make available the LRB design data that reflect 
the sensitivity of the LRB to such requirements as size, environments, loads, and 
interface conditions. 


3.2 SYSTEM REQUIREMENTS 

A vital early task of the LRB prime contractor will be to define the LRB system, 


3-1 



ISTS PROGRAM 

ISIS Simas pcmniic t iiticratioi relatioiships 



Figure 3-1. STS systems engineering and integration relationships. 
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design, configuration, and operational requirements. As shown in Table 3-1, there are 
a large number of complex factors that must be considered in the derivation of basic 
LRB characteristics such as diameter, length, number of engines, and mass properties. 
Major LRB system requirements that will drive the vehicle design and operational 
procedures are summarized below. 


Table 3-1. Examples of factors that can influence LRB design. 


LRB 

Characteristic 

Examples of Influencing Factors 

LRB 

Diameter 

• Proximity to Orbiter and ET 

• Aeroheating effects on Orbiter and ET thermal protection system (TPS) 

• Utilization of existing ET interface fittings 

• Modification requirements for the mobile launch platform (MLP) 

• Orbiter aerodynamic wing loads 

LRB 

Length 

• Aeroelastic effects 

• LRB/ET forward attach loads 

• Stability and control 

• Modification requirements for KSC facilities/GSE 

Number 

of 

Engines 

• Thrust vector control (TVC) authority 

• Abort options 

• MLP flame hole modifications 

• Startup/shutdown sequence 

• Safety/Reliability 

Mass 

Properties 

• Propellant tank arrangement 

• TVC authority 

• LRB/ET interface loads 


3.2.1 ASCENT PERFORMANCE 


The primary groundrules currently being utilized in the development of the LRB 
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ascent performance capabilities are: 


• Provide capability to launch 70,500 pounds to 150 nm orbit. 

• Provide safe abort capability with one LRB or SSME engine out with a 
self-imposed goal of abort to 105 nm orbit with one engine out. 

• Abide by flight constraints such as maximum dynamic pressure, q alpha profiles, 
launch probabilities, and performance reserves. 

It is anticipated that NASA will perform trajectory simulations and wind tunnel 
testing of the integrated vehicle with variations of the configuration and performance 
parameters incorporated into the test activities. These test and simulation results will 
be used to assess the impact of the LRB performance capabilities. The NASA LRB 
Project Office will support these activities by providing the prime contractor with STS 
flight data, including configuration and mass properties data, propellant distribution and 
consumption profiles, engine performance characteristics, thrust vector control authority 
constraints, aeroelastics effects, and other necessary data as requested. 


3.2.2 INTACT ABORT 

Crew safety and mission success are primary drivers in the design of the LRB. 
The basic requirement concerning abort is to provide intact abort capability at any time 
during the launch profile from liftoff through first stage burnout with one engine out. 
GDSS has established the additional goal of providing the capability to abort to a 105 
nm circular orbit with one engine out at any time during the launch profile. The LRB 
Project Office will support the Ascent Flight Systems Integration Group (AFSIG) and 
Abort Panel in performing any required integrated vehicle wind tunnel testing, trajectory 
simulations, and/or analyses of first stage abort options. 
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3.2.3 SAFETY 


The LRB program will adhere to all NASA STS safety guidelines, including those 
set forth in NHB 5300.4 (ID-2) "Safety, Reliability, Maintainability and Quality 
Provisions for the Space Shuttle Program" (see Section 4 of this volume). The LRB will 
be designed to meet STS fail safe requirements and will emphasize design 
conservatism in areas identified as having critical failure modes. Two areas requiring 
special attention are propellant management and engine health verification prior to 
lift-off. The LRB may utilize propellants different than those used on the Shuttle, placing 
new safety requirements on KSC for propellant storage, handling, and servicing. The 
LRB prime contractor will work with the STS Ground Operations Panel (GOP) and KSC 
safety personnel in defining and implementing these new requirements on the KSC 
facilities and personnel. 

Verification of engine health prior to lift-off is a primary safety issue and is 
envisioned to be accomplished in a manner similar to that currently used for the 
SSMEs. LRB safety personnel will assess the procedures to be used as the engine 
ignition sequence and thrust buildup characteristics are better defined. 

Other NSTS systems engineering areas that will be supported by LRB safety as 
required include: 

• Evaluation of LRB interfaces with other Shuttle elements to identify failure modes 
affecting crew safety or mission success. 

• Preparation of Shuttle System Element Interface Functional Analysis (EIFA) 
Documents. 

• System level reliability analyses that affect LRB element interfaces. 

• Support system level hazard analyses by assessing LRB hazard analyses and 
operations data, failure modes and effects analyses (FMEA), and safety study results. 

• Identification and preparation of safety requirements for LRB integrated tests. 
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• Support system level safety studies and, if required, accident/incident 
investigations. 

• Definition of a flight termination system that complies with AFETRM 127-1 and 
SAMTECM 127-1. 

3.2.4 STS COMPATIBILITY 

A major design requirement to be adhered to in the development of the LRB 
configuration is to assure compatibility with the Orbiter, ET, and KSC facilities. This 
imposes design constraints and verification requirements that would not be present in 
the development of a stand-alone launch system. Specific groundrules and design 
goals that have been established thus far include: (1) no redesign of the Orbiter or ET 
structures or thermal protection systems, (2) maximize commonality with existing STS 
elements (e.g., SRB avionics) where cost-effective, and (3) minimize modifications to 
software, GSE, and ground support facilities. 

These groundrules will be assessed in conjunction with the trajectory simulations 
and wind tunnel testing of the integrated vehicle discussed in Section 3.2.1 . These test 
and simulation results will be evaluated to determine the impact of the LRB 
configuration on such launch and flight considerations as aerodynamic flow and 
thermal heating in the proximity of the Orbiter wing and ET, LRB/ET attachment 
interface loads, and the geometric relationship with the MLP flame hole, holddown 
posts, access platforms, and swing arms. 


3.2.5 MINIMIZE DEVELOPMENT AND LIFE CYCLE COSTS 

While safety and performance issues are preeminent in the design and 
development of the LRB, development of a cost-effective LRB concept is critical to final 
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approval and continued success of the program. In fact, the primary rationale for 
minimization of STS impacts is to avoid the significant costs that would be incurred in 
making major changes to that would invalidate the already verified Shuttle system. 
Cost is therefore a principal trade study evaluation criterion and will continue to be of 
paramount concern throughout the design and development phases of the program. 
Among competing LRB design concepts that meet safety, reliability, and performance 
goals, it is expected that development cost and life-cycle cost will be the most 
commonly used figures of merit to arrive at preferred design solutions. As the LRB 
design matures and cost modeling evolved from a parametric to a detailed estimating 
methodology, the SE&I process will be supported by cost estimates of improved fidelity. 

Once the preferred LRB design is selected, emphasis will shift from the use of cost 
as a trade study criterion to the achievement of effective cost management at all levels 
of the program. Reducing costs through such means as innovative production 
techniques, commonality, reduced test requirements, and utilization of existing 
hardware and technology will be emphasized throughout the LRB development. This 
will require the development of a management system that integrates all aspects of 
program information essential to program planning, control, cost estimation, and cost 
control. The LRB Work Breakdown Structure (WBS) will serve as the framework for all 
cost modeling and cost control activities throughout the life of the project. A more 
detailed discussion of cost management activities is contained in Section 2 of this plan. 


3.2.6 EVOLUTION AND GROWTH 

A system requirement that is likely to increase in significance over time is 
development of a capability for LRB evolution and growth. In addition to functioning as 
an element of the existing STS, the LRB could be used as an element of the Advanced 
Launch System, growth versions of the STS, or as a stand-alone expendable booster. 
Use of the LRB for such applications would not only increase the overall utility of the 


3-7 



system, but could also permit increases in production rate for LRB elements, which 
could reduce the cost of the basic STS application. Applicability of LRB concepts for 
these growth missions is therefore an additional consideration in trade studies and in 
the definition of the overall time-phased LRB system. 


3.3 SYSTEMS ANALYSIS 

The complexity of integrating the LRB into the existing STS will require a special 
commitment on the part of the LRB prime contractor to conduct thorough systems 
analysis, which will in turn require in-depth knowledge of the design and operation of 
the Space Shuttle system. Understanding how these STS functions will change with 
the replacement of SRBs by LRBs will be the primary objective of the systems analysis 
conducted to support this program. 


3.3.1 ENGINE ANALYSIS 

The LRB prime contractor shall perform LRB systems analyses with a primary 
objective of defining LRB engine performance capabilities and constraints, with 
emphasis on ensuring compatibility with existing STS elements. This includes 
determining the compatibility of the LRB interfaces with the KSC facilities and 
equipment, SRB avionics, Orbiter and ET software, and ET structural interface 
attachments. Analyses will be performed on the LRB engine to define the performance 
characteristics required to support the systems analyses, tests, and simulations being 
performed on the integrated vehicle. This includes defining the engine characteristics 
for thrust buildup/shutdown, throttling, Isp verification, and thrust vector control. 

Extensive trajectory simulations and wind tunnel testing will be required to define 
the LRB engine operating profile from pre-ignition through first stage shutdown. High 
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fidelity flexible body analyses may also be required to assess the engine startup and 
shutdown phases. Since liquid engines have throttling capability, this approach may 
be considered to minimize vehicle structural loads during critical trajectory phases, 
such as the initial roll maneuver, high q boost, post-high q boost, and pre- and 
post-staging. Throttling will also be considered in first stage abort conditions. The 
results of these additional tests and simulations will be used to define: 

• Engine throttling requirements. 

• Base drag and plume effects. 

• Ignition startup sequence. 

• First stage shutdown sequence. 

• Procedure for performing engine health check during ignition. 

• Engine-out effect on abort options. 

• Booster separation motor (BSM) sizing. 

• Inputs to SAIL test requirements. 

• Engine test stand requirements. 

• Updates to loads model, trajectory profile, thermal design requirements, and 
vehicle performance. 

• Inputs to MLP holddown design requirements. 

Once the LRB preliminary design has been baselined and vehicle and engine 
development progresses, data will be provided to support the ongoing wind tunnel 
testing, trajectory simulations and structural analyses, such as: mold line refinements 
in the nose cone and aft skirt areas; mass properties; BSM characteristics; and engine 
thrust, throttling, startup, and shutdown characteristics. 


3.3.2 AVIONICS ANALYSIS 

The approach to development of the LRB avionics system is to minimize the 
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impact on the Orbiter avionics system by utilizing the current SRB/Orbiter interface 
design. However, the liquid engine will have additional interface requirements, such 
as engine control (startup, shutdown, throttling, and health checks) and fuel/oxidizer 
pressure control. The current approach is to design a single fault tolerant autonomous 
system that will utilize the current SRB/Orbiter interface format. The design options will 
be coordinated with the Integrated Avionics Panel and will provide support as required 
to the Shuttle Avionics Integration Laboratory (SAIL), Shuttle Avionics Software Control 
Board (SASCB), Orbiter Avionics Systems Control Board (OASCB). This activity will 
also include coordinating the instrumentation provisions at the LRB/ET interface that 
are required to support flight test and operations requirements. 


3.3.3 FACILITY REQUIREMENTS ANALYSIS 

The current approach to LRB final assembly and integrated checkout is to perform 
these tasks at the manufacturing facility if possible. This would permit the LRB to be 
shipped directly to KSC and installed on the MLP. However, this requires a 
manufacturing/transportation/storage concept similar to the ET. These study results will 
be coordinated with the Ground Operations Panel and applicable KSC organizations to 
assist in the development of the ground and launch operations requirements for the 
LRB. A more detailed discussion of manufacturing and assembly requirements is 
contained in Section 6 of this plan. 

The KSC ground systems and operations philosophy is to utilize current facilities 
and equipment to the maximum extent possible with minimum modifications. However, 
the LRB has significant differences from the SRB that will affect ground support 
requirements and facilities, including: 

• Larger diameter and greater length. 

• Liquid propellant storage. 
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• Assembly prior to installation on the mobile launch platform (MLP). 


This will require the LRB ground operations activity to be assessed from manufacturing 
through launch. Changes that may be required to the ground support system as a 
result of these new characteristics and requirements include: 

• Redesign holddown release system to reduce vehicle liftoff loads. 

• Increases in MLP flame hole dimensions and nozzle clearances. 

• Reduced assembly provisions in the Vehicle Assembly Building (VAB). 

• VAB work platform modifications. 

• Pad venting modifications. 

• On-pad propellant loading modifications. 

Additional discussion of KSC facility requirements is contained in Section 8 of this plan. 


3.3.4 SYSTEM MODELS 

The LRB Project will support STS systems integration in the development and 
updating of the math models used to support the ascent flight design activities, primarily 
in the areas of loads, aerodynamics, hydraulics, propulsion, consumables, 
environment, and ground and flight simulations. Specific analyses to be performed 
and models to be utilized will include: 

• Interfaces with ET and MLP and the effect of engine startup and pad release. 

• Interfaces with ET and effect of engine-out during ascent and engine shutdown at 
first stage burnout. 

• Acoustic and overpressure effects on launch vehicle at engine ignition. 

• Aerodynamics flow effects on ET, Orbiter, and mated configuration. 

• Base drag and plume effects on ascent performance. 
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• Booster separation modeling, clearance verification, and system definition. 

• Integrated hydraulics/thrust vector control. 

• Propellant loading and consumption. 

• Aerothermal effects on ET and Orbiter. 

• Cryogenic propellant loading effects. 

• Shuttle Avionics Integration Laboratory support (e.g., GN&C simulations, lift-off 
clearances, and separation dynamics). 

• MSFC-mated element system (MMES) simulations. 

• Launch Processing System (LPS) simulations. 

• Detailed modal survey. 

• Failure mode analyses. 

• Overall stress analysis. 


3.3.5 LOGISTICS ANALYSIS 

To ensure that the LRB can be operated in a reliable and cost-effective manner, a 
variety of logistics-related analyses must be performed, beginning in the earliest 
phases of the program. 


3.3.5. 1 Maintainability Analyses 

Maintainability analyses will be performed to assure that LRB flight systems and 
their line replaceable units (LRUs) are accessible for maintenance. LRUs will be 
located and access provided such that minimum time is required to replace or service 
them during vehicle element buildup, verification, and assembly. The LRB will be 
capable of alignment, connection, inspection, and verification of mechanical and 
electrical interfaces during mating operations. The mated LRB will be capable of 
checkout after ground system connection on the launch pad. Accessibility to 
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equipment installations, element interfaces, and service umbilicals requiring 
inspection, servicing, installation, or verification will be provided. 

To ensure maintainability, development of any new ground support equipment or 
facilities will be conducted with full consideration of such factors as fault isolation, ease 
of replacement of failed components, and operating manpower requirements. 
Mockups, simulators, and actual Shuttle operating experience will be utilized to support 
LRB maintainability analyses. 


3.3.5.2 Logistics Provisioning 

The LRB logistics activity will support the STS integrated logistics activity in the 
following areas: 

• Support Shuttle Integrated Logistics Panels (ILP). 

• Support system supply support planning in spares selection and operational 
phase planning. 

• Spares inventory, overhaul capability, logistics capabilities. 


3.3.5.3 Transportation and Handling 

Transportation and handling analyses will be performed to assure that the LRB 
can be transported from its assembly site to its final launch position without degradation 
of reliability. Analyses will be performed to assure that the LRB size and weight does 
not exceed the limitations of feasible transportation and handling systems, that no 
damaging loads are induced in the LRB during transportation and handling, and that 
the LRB is adequately protected against natural environments during transportation 
and handling. 
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3.3.5.4 Training 


Trained and certified personnel must be available to support the LRB from the time 
it leaves the manufacturing facility until liftoff from the pad. It will be the responsibility of 
the LRB prime contractor to support the training and certification of these personnel in 
the areas of LRB handling, transportation, maintenance, repair, overhaul, testing, and 
checkout. The LRB contractor must also support the training of flight crews, flight 
controllers, and other personnel required to support simulator and laboratory facility 
activities involving the LRB. 


3.3.5.5 Logistics Management Information Systems 

The LRB logistics system will be structured to be compatible with the STS 
integrated logistics system and will support the integrated logistics verification 
information system that provides program level visibility over major logistics activities. 
This will include the identification and status of the LRB logistics support posture, 
constraints, issues, and potential problem areas. 


3.4 SYSTEM INTEGRATION 

To meet the challenge of integrating the LRB successfully with the existing Space 
Shuttle system, the LRB prime contractor will have to work closely with several NASA 
centers and the STS integrating contractor to identify and meet all integration 
requirements within the program constraints. This will include careful requirements 
management to assure that all compatibility issues are addressed, performance of the 
technical analyses required to develop an LRB design concept that is fully compatible 
with the rest of the Shuttle system, and continuing cooperation between the LRB 
contractor and the rest of the STS team throughout all phases of implementation. 
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3.4.1 REQUIREMENTS MANAGEMENT 


The LRB Contract End Item Specification (CEI) will be compatible with the 
applicable requirements specified in NSTS 07700, Volume X, Space Shuttle Flight and 
Ground System Specification, and the related system level integrated schematics, 
interface control documents (ICDs), and test and verification requirements. All 
requirements in the LRB CEI Specification will be traceable to Volume X. Conversely, 
the element level system/subsystem specifications, integrated schematics, interface 
control documents, and the LRB Master Verification Plan will be traceable to the LRB 
CEI. All of these categories of documents will be maintained and controlled by the LRB 
configuration management system, which will be developed and implemented to meet 
the requirements of NSTS 07700, Volume IV, Configuration Management. This will 
include providing support to the evaluation, maintenance, and updating of the 
applicable system level specifications, ICDs, and integrated schematics. 


3.4.2 TECHNICAL ANALYSES 

The LRB Project will support the STS mission planning and operations by 
performing LRB technical analyses required to support each STS mission. This will 
include the development, for each STS flight, the LRB mass properties, engine "tag" 
values, propellant loading tolerances, assessment of engine operating power levels, 
and resolution of anomalies from previous flights. Support will also be provided for 
post-flight activities to reconstruct LRB ascent performance for comparison with that 
predicted and to evaluate any in-flight anomalies. These activities will continue to be 
performed in depth until completion of the flight test program and the removal of the 
development flight instrumentation. 
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3.4.3 STS INTEGRATION SUPPORT 


As the LRB continues through the development and verification activities toward 
first flight, support will continue to be provided to the STS program level and systems 
integration activities, especially as it relates to integrated vehicle performance 
verification, interface definition, flight instrumentation requirements, ground systems 
and operations development and verification, configuration control, safety, reliability, 
quality assurance, and logistics. This shall include support to the development of the 
OMRSD/OMI's and interface control documents and to the Launch Systems Evaluation 
Advisory Team (LSEAT) during prelaunch and post-flight evaluations. The extent of 
this support will be as defined and approved in our contract with the NASA/MSFC LRB 
Project Office. Specific areas in which we will provide constructive support to the STS 
systems engineering and integration activities are: 

(1) Mission Requirements and Integration 

-Ascent performance post-flight reconstruction. 

-Ascent Performance Data Book maintenance and update. 

-EO trajectory conditions and abort modes. 

(2) Aerodynamics 

-Aero Data Book. 

-Ascent vehicle aero characteristics. 

-Aero uncertainties. 

-Manufacturing tolerance effects on performance. 

-Wind tunnel test planning and requirements definition. 

(3) Thermal Analysis 

-Element aeroheating math models. 

-Plume effects. 

-Thermal Interface Design Data Book (TIDDB) maintenance and update. 
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(4) IGN&C 

-Six DOF simulations. 

-LRB separation modeling. 

-Engine performance parameters and dispersions. 

-LRB aeroelastic effects and dynamic responses. 

(4) Integrated Avionics 

-SAIL test requirements. 

-Integrated avionics configuration compatibility verification. 

-LPS software requirements. 

(5) Structural Loads and Dynamics Analysis 

-Math modeling; modal data development; external loads; shock, vibration and 
acoustic environments; pogo; flutter and buffet; ignition overpressure. 

-Monitor element dynamic analyses. 

(6) Integrated Propulsion 

-Propellant loading math model. 

-Static test firing plans, procedures, profiles. 

- Pressurization system. 

(7) SAIL Testing 

-Interfaces with MMES and LPS. 

-SAIL Flight System Test and Implementation Plan. 

-SAIL Level II ICD's. 

(8) NSTS Operations Maintenance and Requirements Specification Documents 
(OMRSD) 

-Support systems analyses for accomplishing maintenance and update of LRB 
Assembly and Checkout OMRSD and LRB Prelaunch OMRSD 
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-Assure the Operations Maintenance Plan (OMP)/Operations Maintenance 
Instructions (OMI) are compatible with the OMRSD. 

-Assure OMRSD includes verification of LRB interfaces; end-to-end subsystems 
performance; and mission requirements. 

(9) Support the maintenance and update of the following systems and element ICDs: 


Interface Control Documents - Level II 


ICD-2-12001 

ICD-2-14001 

ICD-2-24001 

ICD-2-00001 

ICD-2-0A001 

ICD-2-0A002 

ICD-2-0A003 

ICD-2-4A001 

-ICD-2-4A002 


Orbiter Vehicle/External Tank 

Orbiter Vehicle/Liquid Rocket Booster (LRB) 

ET/LRB 

Shuttle Vehicle Mold Lines and Protuberances. 
Shuttle System VAB and MLP. 

Shuttle System/Launch Pad and MLP 
Flight Vehicle/LPS Computational System Interface. 
LRB/Receiving and Processing Station 
LRB Retrieval Station (if required) 


- ICD's - LRB Level III 
-ICD-3-44001 
-ICD-3-44002 
-ICD-3-44003 
-ICD-3-44004 
-ICD-3-44006 
Assembly (if required) 
-ICD-3-44007 
-Dwg 10A00332 


LRB/Forward Skirt 
LRB/Systems Tunnel 
LRB/Aft Skirt and TVC 
LRB/ET Attach Ring 

Decelerator Subsystem/LRB Forward Skirt and Nose 
BSM/LRB 

LRB Mold Lines and Protuberances. 
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4 

PRODUCT ASSURANCE 


4.1 APPROACH 


The product assurance program for the LRB will be tailored to meet the LRB 
requirements using the existing General Dynamics Space Systems Division (GDSS) 
Systems Effectiveness Program Plan (SEPP) as a base. The SEPP conforms to the 
requirements of NHB 5300.4 (ID-2) and the LRB program will continue to satisfy the 
requirements set forth therein. The LRB product assurance program shall encompass 
the disciplines of system safety, reliability, maintainability, producibility, and quality 
assurance. 

The Product Assurance Manager will report directly to the LRB Program Manager 
and also to the Corporate Vice-President for Assurance. He shall be responsible for all 
product assurance activities for both the in-house LRB program and all subcontractors 
except for system safety. The System Safety Manager will also report directly to the 
Program Manager in order to assure independent management and assessment of 
system safety issues. The Product Assurance and System Safety Managers will be the 
sole points of contact within the prime contractor for all customer relations in the area of 
product assurance. 

While the SEPP shall represent the guiding document for all product assurance 
activities, a separate System Safety Plan will also be prepared. All plans will specify 
the administrative means and techniques for satisfying the requirements of NHB 5300.4 
(ID-2). These plans will cover all aspects of the LRB program: design, development, 
procurement, production, test, and operations. 


4-1 


The LRB product assurance program will include a motivational program as an 
integral part of the activities of every discipline, to promote awareness among all 
program participants of the importance of their individual efforts to Space Shuttle 
mission success. This motivational program will include goal setting, error cause 
identification and removal, recognition for superior performance, indoctrination for 
supervisory personnel, and distribution of motivational information. 


4.2 SYSTEM SAFETY 

The System Safety Manager will report directly to the Program Manager and 
shall be responsible for preparation and implementation of the LRB System 
Safety Plan. The safety plan will establish the management structure and 
techniques for meeting the requirements of NHB 5300.4 (1 D-2), Chapter 2. 
Existing GDSS plans reflecting experience on Atlas-Centaur, Shuttle-Centaur, 
and Titan-Centaur will be used as a reference. The plan will apply across the 
total LRB Program, including system design and development, test operations, 
flight operations, and subcontractor safety management. 

Major elements of the system safety plan will include definition of organization 
and responsibilities, safety design criteria and trades (including software), 
hazard analysis, control and verification, test requirements, training and 
certification, documentation, and audit. Integration with other technical 
disciplines and with interagency working groups and the phased safety reviews 
of the NSTS Program will be defined. The plan will list the control documents 
and procedures. 

4.2.1 PRELIMINARY HAZARD ANALYSIS 

A preliminary hazard analysis is being conducted. The hazard analysis will 
utilize the hazardous top level event approach. In this approach, top level 
events are defined which incorporate the gamut of hazardous conditions which 
could potentially cause injury or death to personnel, damage to or loss of 
equipment, or other accidents. These hazardous top level events have been 
defined for the Liquid Rocket Booster and are depicted in Table 4-1. 




Table 4-1 

Hazardous Top Level Events 


HTE 001 - 

PERSONNEL INJURY DURING PROCESSING OR FLIGHT 

Hazard Description: Personnel injury results in physical injury or detriment to health of personnel. 

HTE 002 - 

COLLISION/IMPACT DURING HANDLING/TRANSPORTATION 

Hazard Description: Fire/explosion could result in damage to system, 

Aerospace Ground Equipment, facility hardware, facility, or loss of vehicle. 

HTE 003 - 

FIRE/EXPLOSION (NON-ORDNANCE) 

Hazard Description: Fire/explosion could result in damage to system, 

Aerospace Ground Equipment, facility hardware, facility, or loss of vehicle. 

HTE 004 - 

RUPTURE/IMPLOSION OF PRESSURANT/PROPELLANT SYSTEM 

COMPONENTS 

Hazard Description: Rupture/implosion of pressurized containers, vessels, 
or components could result in high energy release and damage to system, 
facility hardware or vehicle and mission loss/delay. 

HTE 005 - 

STRUCTURAUMECHANICAL FAILURE UNDER LOAD 

Hazard Description: Structural/mechanical failure under load could result 
in damage to system, vehicle, facility, facility hardware and mission loss/delay. 



Table 4-1 

Hazardous Top Level Events (Cont'd) 


HTE 006 - 

INADVERTENT ORDNANCE INITIATION 

Hazard Description: Inadvertent ordnance initiation results in unexpected release 
of energy which could damage system, vehicle, and/or facilities. 

HTE 007 - 

PREMATURE/INADVERTENT ACTIVATION OR FAILURE OF 
FLIGHT TERMINATION SYSTEM 

Hazard Description: Premature/inadvertent activation of the FTS could result in loss of the vehicle 
and/or facilities. Failure of the FTS to activate upon command could result in injury to the public or 

damage to property. 

HTE 008 - 

VEHICLE POSITION REQUIRES DESTRUCT 

Hazard Description: Vehicle position requiring destruct could result in loss of 

vehicle and mission failure. 

HTE 009- 

ELEMENT RECONTACT DURING FLIGHT 

Hazard Description: Element recontact during flight could result in structural 
damage and/or loss of system, vehicle, or mission. 

HTE 010- 

IMPROPER BOOSTER REENTRY/IMPACT 

Hazard Description: Improper booster reentry/impact could result in inability to recover liquid 
rocket boosters, damage to the boosters precluding refurbishment, or impact of boosters in an 

area presenting a hazard to the public. 



Potential hazard causes which can lead to a hazardous top level event have 
been categorized as shown in Table 4-2. The hazard analysis will be 
organized by hazardous top level event. Within each top level event, hazard 
causes will be defined by subsystem and subsystem elements as well as by 

cause category. 


Table 4-2 
Cause Categories 

S/M : Structural/Mechanical 
MAT : Material 

CON : Contamination/Corrosion 
ELE : Electrical 
CHE : Chemical 
ENV : Environmental 
PRS : Pressures 
PYR : Pyrotechnics 
PRO : Propulsion 
RAD : Radiation 

EMI : Electromagnetic Interference 
T/A : Toxicant/Asphyxiant 
THE : Thermal 
IMP : Impact/Collision 
OPE : Operator Error 
PRE : Procedure Error 


SWE : Software Error 



Causes which can lead to more than one hazardous top level event will 
normally be reported under the event which would occur first. 

At least one control will be established for each hazard cause. Controls may 
either be design or procedural. The optimum control is a design feature that 
ensures the inherent safety of the vehicle and crew, associated ground support 
equipment, facilities, and personnel to the maximum extent possible. Particular 
attention will be given to primary system design to assure that any gradual 
deterioration of a function will permit detection of the hazardous condition in 
time to effect control counteractions. If risks cannot be totally controlled by 
design action, they can be controlled by safe devices such as mechanical 
barriers or inhibiting mechanisms; by protective systems such as fire 
extinguishing systems, radiation shielding, or personnel protective equipment; 
or by warning devices which are used in conjunction with proper emergency 
plans and procedures. Finally, when none of the foregoing actions are possible 
or applicable, procedural control will be utilized to limit the initiation of a 
hazardous sequence of events. 

Each hazard control will be verified. This verification will be documented in the 
hazard analysis. Verification can be by inspection, analysis, or test. For an item 
to be closed, the verification must be complete. 

Prior to processing and first launch of the liquid rocket boosters, as many 
hazard items as possible will be closed. For any item remaining open, the risk 
of proceeding will be assessed. This risk must be found to be acceptable by 
both contractor and government program management. 

The system safety organization has been actively involved in the trade studies 
leading to the proposed liquid rocket booster concepts. The proposed concepts 
have been reviewed from a safety viewpoint. All of the approaches involve 
state of the art technology with no associated high risk safety factors. Detailed 
risk assessment of the proposed concepts will be continued through concept 
development and the hazard analysis process. Two areas, propellant 
management and engine health verification prior to liftoff, require special 
attention. Three of the proposed concepts use propellants that are not currently 
found on the STS launch complexes. Two concepts utilize RP*1 and one 



concept utilizes liquid methane (CH4). Verification of engine health prior to 
liftoff is a primary safety issue and is envisioned to be accomplished in a 
manner similar to that currently used for the SSME's. System safety will assess 
the procedures to be used as the engine ignition sequence and thrust buildup 
characteristics are better defined. 

4.2.2 SYSTEM SAFETY CRITERIA AND REQUIREMENTS 

Safety requirements for LRB planning, design, manufacturing, testing and 
operations will be developed and documented as an integral part of the hazard 
analysis and risk assessment. System safety will perform a risk comparison 
during trade studies to include areas such as fail operational/fail safe 
combinations; equipment and functional redundancies, and operational 
considerations. All Category I and II failure modes identified in the Failure 
Mode and Effects Analysis will be incorporated in the hazard, analysis where 
system safety will define controls and verifications thus providing a closed loop 
tracking system for these failure modes. System safety will place special 
attention on liquid rocket booster interfaces with the STS orbiter with emphasis 
on all aspects of crew and vehicle operations and procedures. Stress safety 
factors will be totally evaluated in terms of both test and operational 
requirements. Safety consideration will be given to all aspects of integrated 
facility, ground support equipment and vehicle operations. System safety will 
coordinate activities with industrial safety and test operations safety to ensure 
an effective and integrated safety effort. The application of hazard control will 
consider severity, frequency and cost factors in terms of impact potential, design 
options, reaction time and procedural controls. 

4.2.3 TECHNICHAL RISK MANAGEMENT SUMMARY 

A composite listing of all identified technical risks and hazards with associated 
control actions is being developed in conjunction with the refining of design for 
the proposed concepts. As no high technology development has been 
identified for the liquid rocket boosters, technical risk appears to be managable. 
Primary safety related technical issues will evolve around those concerns 
associated with interface of the liquid rocket boosters with the Shuttle stack, 
interfaces and modifications required at the Shuttle launch complexes, and 




operational interfaces required to minimize risk to the flight crew. To ensure all 
technical risks are properly identified, system safety personnel are totally 
involved in trade studies, the design process and the management process for 
the liquid rocket booster program. In addition, system safety reviews technical 
analyses including FMEA's, stress analysis, thermal analysis and dynamic 
analysis and incorporates these analyses into the overall hazard analysis and 
technical risk assessment. 


4.3 RELIABILITY 

The Reliability Engineering function will report to the Systems Engineering 
Director and will be responsible for preparation and implementation of the LRB 


Reliability Plan. The reliability plan will establish the means for meeting the 
requirements of NHB 5300.4 (ID-2), Chapter 3. GDSS experience on Atlas-Centaur, 
Shuttle-Centaur, and Titan-Centaur will be drawn upon as applicable in the 
preparation and execution of reliability plans. The plan will apply across the total LRB 
Program including subcontractors. 

Reliability engineering shall be an integral part of the design and development 
process and will include the evaluation of hardware reliability through analysis, review, 
and assessment. Reliability tasks will emphasize the qualitative and quantitative 
evaluation of hardware and operations including ground support equipment and 
launch vehicle interfaces. Supplier control will be defined to assure that the 
performance of system elements obtained from subcontractors and suppliers meets the 
reliability requirements of the overall system. 

Reliability design criteria will be defined for trade studies and subsystem design. 
A system will be established for the preparation, maintenance, and control of Failure 
Modes and Effects Analyses (FMEAs) and Critical Items Lists (CILs). Controls for the 
selection and use of Electrical, Electronic, and Electromechanical (EEE) and 
mechanical parts will be a major emphasis of the reliability plan. A system will be 
defined for the selection, specification, qualification, tracking, problem reporting and 
corrective action, and control of EEE parts throughout the program. 

The reliability plan will include a system for monitoring the hardware certification 
program and the acceptance testing program to assure that all requirements are 
adequate to detect manufacturing defects and to assure performance verification. 


4.4 MAINTAINABILITY ASSURANCE 

The Maintainability function will report to the Systems Engineering Director and 
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shall be responsible for implementation of the LRB Maintainability Plan. The 
maintainability plan will establish the means for meeting the requirements of NHB 
5300.4 (ID-2), Chapter 4. Existing GDSS experience on Atlas-Centaur, 
Shuttle-Centaur, and Titan-Centaur will be drawn upon as applicable. The plan will 
apply across the total LRB Program including subcontractors and will identify each 
maintainability task and describe how each task will be performed. 

The maintainability efforts will emphasize maintainability traits associated with 
accessibility and remove/replace actions that can be anticipated during prelaunch 
activities. Maintainability design guidelines and checklists will be provided to assist 
design engineers in evaluating the qualitative maintainability features of the design. 
Maintainability engineers will monitor design efforts to identify and assist in resolving 
maintainability issues by participating in design meetings, tradeoff studies, and 
over-the-board discussions with design engineers. 

The maintainability engineers will review design items that may have significant 
man-machine interfaces to ensure that human engineering principles are properly 
incorporated. 


4.5 QUALITY ASSURANCE 

The Quality Assurance organization at GDSS is headed by the Division Vice 
President, Quality Assurance and will have responsibility for implementation of the LRB 
Quality Assurance Plan. The current GDSS quality assurance plan meets the 
requirements of NHB 5300.4 (ID-2), Chapter 5. This operating, in-place system will be 
modified to incorporate the unique requirements of the LRB Program, and the 
innovations associated with our preventive quality assurance approach (Section 6.3.4) 
as they are proven to be effective. The plan will cover the total LRB Program including 
subcontractors. Features of the plan include: 
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• Quality planning 

• Independent quality organization/reporting 

• Drawings/Specifications/Procedures review and approval 

• Support for design reviews 

• Change control 

• Documentation control 

• Purchase Order reviews for requirements 

• Source inspection 

• Major Subcontractor controls 

• Receiving inspection 

• Metrology controls 

• Manufacturing Planning and Tooling review and approval 

• Certification of personnel 

• Inspection; Configuration verification 

• Fabrication control 

• Test monitoring 

• Measuring and Test Equipment control 

• Material Review Control 

• Property control 

• Process control 

• Contamination/cleanliness controls 

• Handling/packaging controls 

• Stamp controls 

• End-item acceptance 

• Nonconformance controls 

• Corrective action 

• Audits (systems requirements compliance and area surveillance) 
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5 

DESIGN AND DEVELOPMENT 


5.1 DESIGN APPROACH 


The primary objective of the LRB design and development effort will be to 
generate a safe, reliable, low cost design that can be readily integrated with the STS. 
Our design approach is to maximize the use of proven design concepts that offer 
sufficient performance margins. Early tradeoff and sensitivity studies will address 
performance vs. complexity, weight, cost, and risk. A commonality plan will be 
completed prior to the Preliminary Requirements Review (PRR). 

The design group will be organized for rapid reaction and response to overall 
program requirements by including staff representatives from all major elements of the 
LRB Project organization. A staff responsibility will be to focus support for the Systems 
Integration Review, Ascent Flight Systems Integration Group, and the Interface Working 
Group for the preparation and coordination of IRDs and ICDs. 

Early identification of design requirements will enhance a simple compatible 
approach. A design goal is to provide an LRB that minimizes the impact on all STS 
elements. Accomplishing this goal will minimize the amount of testing required to verify 
the interfaces. Wherever possible, materials will be selected from those already used 
in the STS program to maximize the use of existing technology and eliminate the need 
for advanced materials research. Design reviews, such as the PRR, PDR, and CDR, 
will be scheduled at strategic points in the design and development process to assure 
a coordinated program that satisfies all functional requirements. 
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5.2 FLIGHT HARDWARE 


While proven technologies will be used during design and development of the 
LRB, the foremost program concern will be to improve Shuttle safety by eliminating 
failure modes, reducing criticality of failure, and providing additional abort modes and 
approaches. Enhancement of Shuttle performance and relaxation of Shuttle operating 
constraints are other key requirements that will be used as a basis for determining and 
implementing the preferred design and development approach for the LRB. 


5.2.1 STRUCTURES 

In the design and development of LRB structures, we will strive to ensure 
downstream producibility by recognizing the manufacturing implications of our design 
concepts. Aluminum will probably be the basic structural material used in our LRB 
structures. The properties and use of this material are well established, minimizing the 
cost and risk of materials development and fabrication. The tanks are designed as 
monocoque and semi-monocoque vessels that will support the STS "stack" in the 
vented condition freestanding, during flight readiness firings, and during liftoff 
transients. 

While the use of aluminum will facilitate materials development and fabrication, 
some forming development may be required, due to the thicker skin requirements (up 
to one inch) of the pressure-fed system. The juncture of the tank dome, cylinder, and 
adapter flange will require development efforts to ascertain the strength impact or 
subsequent treatment, if required. 

As part of the LRB structure and tankage development, significant analysis and 
testing will be required. To reduce costs, we recommend using analysis, computer 
simulation, and reduced scale model test verification in lieu of full scale testing 
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whenever possible (see Section 7). For example, a significant amount of structural 
analysis will be needed to determine pre-ignition, launch, and flight loads into the 
various elements of the STS stack. Many of these analyses can be performed using 
tools already in widespread use at GDSS, such as NASTRAN. However, a full scale 
structural item will be required to verify fabrication and for pressure proof tests. 
Propellant flow tests and sensor verification will also be required. These tests can be 
performed at the contractor's facility or at MSFC. 


5.2.2 SEPARATION SYSTEM 

Due to its commonality with the SRB separation system, the LRB separation 
system should require relatively modest development effort. However, as both the 
pump fed and pressure-fed LRB concepts are longer than the SRBs, extensive 
separation dynamics investigation will be required to assure adequate and clean 
separation under all conditions, including abort modes. Separation dynamics 
evaluation should be conducted by mathematical simulations supported by subscale 
model wind tunnel testing. Math modeling and analyses can be performed by the 
contractor. Wind tunnel testing and mechanism separation verification are best 
conducted at government facilities such as those located at MSFC. 


5.2.3 THERMAL CONTROL 

The LRB will utilize passive thermal protection and control, consisting of various 
types of insulating materials. If liquid hydrogen is used, there will be an additional 
requirement for active thermal control systems to vent the LH2 tanks. The three critical 
areas of the LRB that will require passive thermal protection are: 

a) protection of the nose cone and aft skirt from ascent heating 
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b) prevention of ice accumulation on cryogenic tanks and feed lines 

c) protection of the pressurization tank from excessive heating. 

Thermal protection for ascent heating can be achieved by deploying an ablative 
insulating material on the nose cone and aft skirt in a manner similar to that currently 
used for the ET. Analyses and trades early in the design and development phase must 
be performed to determine whether this represents the best approach for the LRB. The 
L02 tank can be insulated utilizing a similar technique. The pressurization tank will 
probably also require the use of insulation. If it is determined that existing thermal 
protection techniques can be applied to the LRB, little new development will be 
required. An applications demonstration and verification can be made on a 
flow-through full scale test article. 


5.2.4 PROPULSION 

The pump-fed and pressure-fed LRB concepts both require new booster engines. 
Development of new man-rated engine systems represents a significant design and 
development task; in the case of the LRB, propulsion system development will 
represent a large share of the overall DDT&E effort. 


5.2.4.1 Engines 

Efficiency requirements for pump-fed LRB engines can be relaxed, since 
additional propellant in the LRB can be substituted for engine inefficiency. This will 
allow the application of current pump-fed rocket engine technology. Engine chamber 
pressure should be optimized to permit the use of a larger, lower speed turbo-pump 
system that minimizes concerns regarding bearings, shafts, and seals. The planned 
oxidizer-cooled gas generator engine cycle is a well established design concept. The 
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development effort for this new engine would be much less than that associated with 
complex, highly efficient engines such as the SSME. Initial engine development 
should be at the engine contractor's facility. Pressure-fed engine tests will be 
conducted at NASA/MSFC. Cluster firing tests can be performed at MSFC or NSTL. 

The pressure-fed engine development philosophy should be the same as for the 
pump fed; i.e., to emphasize propellant energy rather than efficiency to reduce 
complexity. While pressure-fed engines are generally simpler than pump-fed engines, 
the size of the pressure-fed engines that will be required for the LRB introduces several 
complexities. As is the case with pump-fed engines, full scale development, 
fabrication, and test firing of pressure-fed engines can be conducted at the engine 
contractor's facility, with cluster firing tests performed at MSFC or NSTL. 


5.2.4.2 Engine Feed System 

The propellant feed system must be designed to minimize losses and to eliminate 
inactions such as geysering and POGO. Sump screens will be needed at each inlet 
from the tanks. For the pump-fed engine concept, fuel lines are routed with the bellows 
to allow for head-in gimbaling. For the pressure-fed engine, high pressure gimballing 
lines, including a L02 feed line through the center of the RP1 tank, may be required. 
These would pose new development challenges, although relatively little new 
development will be required for the pump-fed systems. Layout, flow characterizations 
and evaluations can be accomplished utilizing the full scale flow test LRB assembly. 


5.2.4.3 Pressurization 

Pressurization systems for both pump-fed and pressure-fed LRB concepts 
currently utilize helium. The pump-fed version can utilize a 50 psia system similar to 
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that used on existing L02/RP-1 launch vehicles. It requires almost no development, 
with the exception of a demonstration using the full scale LRB flow test article. The 
pressure-fed LRB, which requires larger volume propellant vessels maintained at much 
greater pressure, represents a greater challenge in the pressurization system 
development. The proposed Tridyne system would entail a significant design and 
development effort to assure applicability and safety. This activity should be done at 
the contractor's facility. Final testing and demonstration would be with the full LRB 
engine demonstration. 


5.2.5 ELECTRICAL POWER 

The LRB will have a self-contained power system independent of that used by the 
Orbiter. Prior to lift-off, ground power facilities at the launch pad can be used for all LRB 
functions. After lift-off and umbilical separation, on-board power will be provided by an 
autonomous source such as batteries. Back-up batteries will be needed for 
mission-critical fuctions such as engine shutdown and LRB separation. The batteries 
and power distribution and management system will maximize the use of established 
technologies to minimize the design and development effort. A functional brassboard 
arrangement will be constructed to demonstrate and verify operations for all mission 
conditions. Full assembly verification shall be performed utilizing the full-up, full scale 
LRB systems test, and should be conducted at the NSTL. 


5.2.6 AVIONICS 

LRB commands and telemetry with the Orbiter will be through the OIU. The Orbiter 
to LRB input/output functions and interfaces will be similar to those utilized by the SRB, 
reducing development time and cost. Other LRB avionics functions will be unique, 
requiring development and verification and validation of programmed software. The 


5-6 



avionics system design and development will be sequential simulations. Multi-element 
computer simulation of the planned avionics architecture will be developed initially. 
Brassboards of the elements will then be connected for design verification; followed by 
element production model items substitution. First production elements will be verified 
by hardwire hook-up to a computer-stimulated OIU for all mission parameters. A 
complete avionics system is to be included in the full-up, full scale LRB propellant flow 
tests and cluster engine firings. All computer and element simulations are to be done 
at the contractor's facility. Installation, checkout, and demonstration on the full-up, full 
scale LRB will be at the NSTL. 


5.2.7 ORBITER AND EXTERNAL TANK 

The increased length of the LRB relative to the SRB may introduce increased 
loads into the ET. Identification of design impacts and load verification will require wind 
tunnel testing and detailed loads analyses. These tests should be conducted with a 
scaled model at an existing government facility such as MSFC or AEDC. If the loads 
into the ET fittings exceed design allowances, ET design modifications will be required. 
The full-up, full scale LRB should be attached to an ET, as a structural simulator, for 
cluster firing tests to evaluate dynamic responses. To avoid the high cost associated 
with development of a full scale mock-up, an electronic mock-up should be used to 
verify electrical interfaces between the LRB and ET. 


5.3 GROUND SUPPORT EQUIPMENT (GSE) 

5.3.1 FACTORY 

Many LRB elements will be designed, developed, and manufactured by 
subcontractors who specialize in those specific technologies. Remaining LRB 
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elements and final assembly will be performed at a plant designed and built by the 
prime contractor. The assembly plant will be designed to receive, inspect, and store all 
LRB elements received from subcontractors, as well as to support fabrication and 
check-out of the LRB. The final assembly facility can be located anywhere with 
convenient access to the launch site, although verification and transportation 
requirements can be reduced if the plant is located in the local KSC area. 


5.3.2 TESTING 

Initial component testing will be the responsibility of the LRB suppliers. 
Development testing of the flight hardware will be performed at a variety of locations, 
including the final assembly plant, NSTL, and MSFC. During the development 
program a full size LRB test article must be provided for prototype proof and vibration 
testing, which can be performed at MSFC test facilities. A more detailed description of 
LRB verification requirements and plans is contained in Section 7 of this document. 


5.3.3 TRANSPORTATION 

Commercial transportation modes can be used throughout the development and 
production of either the pump-fed or pressure-fed LRB concepts. The pump-fed 
concept component dimensions are such they all can be shipped via truck or rail to the 
prime contractor's assembly facility. For the pressure-fed LRB, rolled formed tank 
segments will have to be shipped by inland water ways because the LRB diameter is 
likely to exceed the 14-foot height (above road bed) and width limits of the interstate 
highway system. Shipment of the assembled LRB from the assembly plant, to the 
NSTL for testing, and to KSC for launch will be via inland waterways or along the coast. 
Barges of the type constructed for Saturn stages or the ET are applicable for the 
assembled LRB. If LRB final assembly is performed in the vicinity of KSC (see Sections 
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6 and 8), transportation requirements will be greatly simplified. In any case, no major 
new transportation development is envisioned for the LRB program. 


5.3.4 LAUNCH SITE 

New ground support handling equipment will be required for the LRB. If the LRB 
is shipped to the launch site from a distant location, it will be delivered in the horizontal 
mode. New equipment will have to be designed for use at KSC to rotate the LRB to the 
vertical position for stacking in the VAB. All of the LRB launch site ground support and 
handling equipment will be designed and developed by KSC in conjunction with the 
LRB contractor. This GSE will be verified with the LRB check-out unit. 

While all LRB avionics and electrical circuits will be checked via the ATE at the 
assembly site prior to shipment, a duplicate ATE will be sent to KSC during 
development to interface with the LPS evaluator to verify compatibility. This ATE GSE 
will be designed and developed as part of the avionics development task discussed in 
Section 5.2.6. The LPS evaluator modification development will be conducted by KSC 
in conjunction with the LRB contractor. Facilities must also be developed at the launch 
site for installation of batteries and pyrotechnic devices on the LRB. A more detailed 
discussion of KSC requirements and facilities is contained in Section 8 of this 
document. 


5.4 SOFTWARE 

5.4.1 SCHEDULES AND PLANS 

Four types of software will be required for the LRB: software required for internal 
LRB operations, software needed for ATE operations, software to simulate the Orbiter 
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side of the OIU during testing, and LRB-ET-Orbiter software. The development plan for 
LRB and ATE software is to conduct this effort in parallel with avionics development, 
first creating software for simulations, followed by development of software for the 
development test programs, and ultimately the development of software to support LRB 
operations. 


5.4.2 FLIGHT SYSTEMS 

The software to support LRB flight will be developed in three phases: initial, 
demonstration, and final. All software will be tested to assure adequate responses for 
all mission aspects. The primary focus of the development of LRB flight systems 
software will be to assure LRB safety, reliability, and ability to meet mission 
requirements. 


5.4.3 GROUND SYSTEMS 

A variety of software programs will be required for the many ground systems that 
will be needed to support evaluation activities. At the assembly plant, software 
programs will have to be developed or modified for the ATE, automated fabrication 
equipment, and quality assurance operations. At the launch site, software will have to 
be modified or developed to support numerous computer-controlled evaluations. 
These include receiving, post-stock and pre-launch to lift-off control, and evaluation 
software for the LPS. It is expected that LPS software will be developed and verified by 
KSC with requirements provided by the LRB prime contractor. 
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5.5 ADVANCED/NEW TECHNOLOGY DEVELOPMENTS 


Since the philosophy of the LRB design and development program is to reduce 
cost and risk by maximizing the use of existing technology, there will be relatively little 
development of new technologies. Many of the new technologies that are developed 
will relate to the development of LRB engines. The LRB tanks and structures employ 
established design and fabrication techniques with aluminum. To reduce weight and 
size it would be desirable to utilize a lighter aluminum/lithium alloy. This would entail 
some advanced manufacturing technology development. As advanced development 
work is continuing on Al/Li, the degree of additional development efforts for LRB 
applications will depend on the status at the time of LRB acquisition commitment. 


5-11 



6 

MANUFACTURING 


6.1 APPROACH 

The manufacturing approach for LRB requires total prime contractor commitment 
to support the program from concept development to test and checkout prior to final 
shipment. The following sections further define the methodology and support functions 
of manufacturing and their relationships to the program. 


6.1.1 PRODUCIBILITY 

Efficient manufacturing begins with the cooperative efforts of design and 
producibility engineers. Producibility engineers will actively participate in all trade 
studies, engineering reviews, and concept reviews to assure that manufacturing 
considerations are incorporated into the design. Producibility engineers will report to 
the LRB Program Manager as well as to their own functional manager. In this 
environment, they will not only be kept abreast of the program commitments, but can 
also maintain continuity with the new manufacturing technologies being developed on 
other programs. 

The producibility engineer will be colocated with the design engineers and will be 
an integral contributor to the design process. The prime objective of the producibility 
engineer will be to provide the design staff with the most economical methods to 
manufacture concepts that can be accomplished within the production environment. 
The producibility of a new vehicle is largely driven by the methods used to develop a 
specific design. The LRB design will therefore reflect the best capabilities of 
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manufacturing to reduce cost and risk. Advancements in the manufacturing process 
will be assessed to identify ways to reduce cost and risks. The basic design concepts 
will be coordinated with the producibility engineer. Various production approaches 
shall be examined, and those that best accomplish the intent of the design while 
meeting the criteria for a production environment will be selected. 

By coordinating the designs at the concept level and providing manufacturing 
input, the producibility engineer effectively begins the process of establishing the 
preliminary manufacturing plan. 


6.1.2 MAKE/BUY PHILOSOPHY 

The preliminary manufacturing approach for the LRB is to provide in-house 
assembly, test, and checkout of the vehicle, and to procure from subcontractors the 
detail components and sub-assemblies that go into those assemblies. With this 
approach we will best utilize each vendor for their expertise and eliminate expenses 
normally accrued through internal facilitization, training, tooling, personnel, and 
maintenance. The manufacture of certain sub-assemblies, such as the weld 
assemblies of the fuel and oxidizer tanks, will remain in-house to take advantage of 
General Dynamics' proven capabilities in these critical processes. As the concepts and 
designs for the LRB evolve, the Make/Buy policy will be refined. 


6.2 MANUFACTURING FACILITIES 

The manufacturing facilities will support final assembly and checkout of the LRB 
prior to shipment to the launch facility. The location of the final assembly facility has not 
yet been determined. Locating the final assembly facility at or near the launch site 
would eliminate costly and potentially hazardous transportation problems. If the final 
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assembly facility is not located at the launch site, certain checkout procedures may 
need to be performed twice, once at the factory and again at KSC. Depending on the 
distance between the factory and launch site, this could require costly duplication of 
manpower. Conversely, lower manufacturing costs might be achieved if the factory is 
located away from the KSC area. 

The level of automation to be utilized within the facility will be determined in future 
phases of the program. To minimize program costs and risks, the automation 
guidelines will be guided by both cost and reliability considerations. Due to low 
projected launch rates (6-14/year), automation may not be as cost-effective in certain 
manufacturing applications as it would be for a higher production program. However, 
with sufficient commonality of components, benefits of automation could be increased. 
Automating certain parts of the production process might also help improve quality by 
increasing consistency, thus reducing program risk and the cost of rework. 


6.3 MANUFACTURING CONTROL 

Effective control of the manufacturing process consists of four major elements: 
development of sound manufacturing methods, effective planning, tooling, and quality 
control. These important program considerations are summarized below. 


6.3.1 METHODS 

The basic manufacturing plan will be established during the Preliminary Design 
phase by producibility function, and will be constantly updated as the design evolves. 
The manufacturing plan will also grow in detail to support manufacturing, estimating, 
and scheduling. Tooling, process planning and manpower loading of the program will 
be derived from this plan. 
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A Manufacturing Breakdown Structure (MBS) will be developed. The MBS will 
outline and control the manufacturing process and provide direct traceability to the 
Work Breakdown Structure (WBS). Figure 6-1 shows an example of an MBS for a 
liquid oxygen tank design concept. 


6.3.2 PLANNING 

The planning function will receive their work instructions and direction from the 
manufacturing plan. This function will be supported by manufacturing engineers who 
provide formal work instructions to the manufacturing departments. The work 
instructions will be developed on a computer and controlled electronically to provide 
paperless planning to the factory floor, and will be coordinated with receiving and 
production control to allow a smooth flow sequence. 


6.3.3 TOOLING 

Basic tooling concepts will be developed by the producibility function during the 
concept development process. These tooling concepts are an integral part of the 
manufacturing process and the development of capabilities to support these processes. 
Figure 6-2 shows a tooling concept for a radial weld fixture that may be selected for 
welding tank bulkheads. 

Figure 6-3 shows a tooling concept for an adjustable length weld fixture for joining 
tank constant sections and rings. These tooling concepts lend direct support to the 
process planning, estimating, scheduling, manpower loading, factory layout 
development, and the eventual design of the tool. 
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Figure 6-1. Sample manufacturing breakdown structure for LRB liquid oxygen tank. 
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Figure 6-2 . Tank bulkhead weld fixture tooling concept. 



Figure 6-3 . Adjustable trunnion mounted weld fixture concept. 
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6.3.4 QUALITY 


Our quality control is applied early in the design and manufacturing planning . 
process to prevent potential problems before they have a chance to occur. By 
preventing errors early in the manufacturing process, we can eliminate the scrap and 
rework normally associated with the traditional quality format. Scanners, probes, and 
vision systems can be built into the manufacturing process to provide a closed loop 
network that detects a problem and automatically alters the process to compensate, 
thus preventing product nonconformances. To meet the goals of the LRB Program, our 
plan is to use a combination of Total Quality Control (TQC), "Transition From 
Development To Production" DoD Directive 4245.7 (Willoughby Templates), and 
Taguchi’s approach (see Figure 6-4). These methods represent a cost 
reduction-oriented approach for product and process optimization, providing an 
economical means of achieving high quality product. Taguchi's "Systems Design" will 
assist the design engineer in developing design approaches that meet both cost and 
quality criteria. 


6.4 FLIGHT HARDWARE 

6.4.1 STRUCTURES AND MECHANISMS 

In the area of structures and mechanisms, there will be many opportunities to 
utilize state of the art manufacturing methods to reduce costs and to improve quality. 
The utilization of advanced materials and processes to develop structures such as the 
bulkheads for both fuel and oxidizer tanks will be explored and developed. Different 
approaches to fabricating adapters to reduce manufacturing flow times and cost will 
also be reviewed and alternatives recommended. Reduction of piece parts by 
combining more than one structural shape into a common extrusion, precision casting, 
forging, superplastic formed panel or integrally machined part will be studied to reduce 
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the cost and manufacturing risks of product development. Extensive use of Variable 
Polarity Plasma Arc Welding (VPPAW) and real time radiography will be utilized in the 
structural build up of many components. Many new processes show promise for 
application in the manufacture of our LRB design concepts, although some will require 
further testing and evaluation. 


Off-line and On-line Quality Control Via Taguchl 



•INNER NOISES 


ILLUSTRATION COURTESY OF DR. DON CLAUSING 
MASSACHUSETTS INSTITUTE OF TECHNOLOGY 


Figure 6-4 Taguchi method of quality control. 
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Several existing manufacturing technologies will also be utilized to reduce the 
cost of manufacturing. Processes such as shear forming, spin forming, power feed 
drilling, automatic riveting, flash welding, and resistance welding will be reviewed and 
implemented where practical. Some of these technologies will also require up-scaling 
to be usable on large components. 


6.4.2 SEPARATION SYSTEM 

Should the booster motors for separation utilize the existing boosters for SRMs, 
manufacturing concerns are minimal, relating only to the installation procedure. If the 
booster motors are upscaled, installation and assembly becomes an easier task but 
test and evaluation hardware will have to be developed for acceptance of the new 
design. 


6.4.3 THERMAL PROTECTION 

The application techniques anticipated for applying ablative insulating material to 
the LRB may be similar to that currently used for the ET. Insulating fuel lines where a 
spray-on type insulation would not suffice does not pose a problem, nor is any special 
equipment anticipated for its application. The actual location for application of the 
thermal protection is dependent on the site selection for the manufacturing facility and 
its proximity to the launch facility. As further definition is provided to the design, the 
manufacturing plans will be refined. 


6.4.4 MAIN PROPULSION 

The vehicle prime contractor shall work closely with the engine contractor to 
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eliminate the complexities of engine installation and ground operations, while still 
meeting the safety and reliability requirements for the program. Modularity of the 
engine cluster would facilitate ease of assembly, installation, and ground operations 
functions, and enable more efficient maintenance. Weld joining of the fuel lines would 
improve the reliability of these connections and reduce the assembly risks incurred by 
multiple fastener coupled joints. 


6.4.5 AVIONICS 

Modular avionics packaging will be manufactured and validated by the individual 
subcontractors supplying the components to the program. Special tooling is not 
anticipated for installation and integration of the avionics components into the vehicle. 


6.4.6 ELECTRICAL POWER 

Electrical power units will be manufactured and validated by the individual 
subcontractors supplying those units to the program. Special tooling is not anticipated 
for installation and integration of these units. Wiring harnesses will be fabricated 
off-site' from physical description data down loaded from the CAD design of the vehicle. 
Harnessing modules will be installed manually or by automated systems within the 
assembly area. 


6.5 ASSEMBLY AND CHECKOUT 

Part fabrication and some subassembly manufacturing will be provided by 
subcontractors that specialize in those specific technologies. All components will be 
inspected and checked out prior to shipment to the final assembly facility. Each level of 
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assembly and installation will provide in-process inspection and checkout of the 
assembly and systems build-up. The next higher level of checkout will require only 
interface checks required to verify that systems are functional. The final test and 
checkout prior to shipment to the launch facility will provide a total integration checkout 
verification. A more detailed discussion of LRB verification is contained in Section 7 of 
this plan. 


6.6 GROUND HARDWARE 

Assembly and installation material handling and transportation equipment will 
utilize common equipment with the ground operations function to minimize tooling 
costs. A detailed description of ground hardware to be used at the launch site is 
contained in Section 8 of this plan. 




7 

VERIFICATION 


7.1 APPROACH 

Our LRB development plan includes establishment of an integrated verification 
management program to provide efficient and cost-effective control of the verification 
process. This concept, shown in Figure 7-1 , illustrates the fact that verification will be 
an integral part of the hardware/software design, fabrication, and acceptance process. 

Our approach will require and achieve uniform application of requirements across 
the entire design, manufacturing, and operations process for all LRB components and 
systems. It will emphasize commonality of data requirements, test requirements, 
procedures, system models, software support equipment, and functional simulations. It 
will also emphasize the utilization of built-in test (BIT) in all test activities and will 
provide the guidelines, criteria, and format for test data, test procedures, test reports, 
and verification compliance closeout documentation with NASA/MSFC. 

The LRB verification process will be implemented in accordance with the 
LRB Verification Plan. This plan will describe philosophy, management, and controls, 
as well as an overall description of the use of verification methods for the LRB program. 
It will include all verification activities from the design phase to verification closeout. It 
will define verification requirements for deliverable hardware, software, support 
equipment, utilization of major ground test articles, and new or existing test facilities. 
The LRB Verification Plan will be developed by the prime contractor and shall be 
subject to the approval of the NASA Marshall Space Flight Center (MSFC). 

Prior to initiating development of this plan, we will review the SRB Master 
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Verification Plan (MVP), using this document as a guide where appropriate. We will 
incorporate the procedures into the LRB Verification Plan to ensure rigorous 
documentation and closeout of verification requirements. 

Our approach will take into consideration the many facets that drive the verification 
activities in the development of requirements and the application of methods to meet 
requirements. Key features of the LRB program that will affect verification 
requirements and procedures are as follows: 

a. The LRB will be used for STS manned missions. 

b. The LRB will provide very high thrust levels. 

c. The main engine area will be subjected to a very high vibro/acoustic 
environment. 

d. The LRB will perform during a very critical period of flight. 

e. Two LRBs will perform in parallel during their normal use. 

f. The LRBs are an integral part of the Space Shuttle system. 


7.2 VERIFICATION PROCESS 

Figure 7-2 depicts the verification process, illustrating that the process includes 
four major activities: (1) development of verification requirements based upon design 
requirements, (2) application of methods for accomplishing verification, (3) evaluation 
of results against established design and performance requirements, and (4) 
documentation to ensure design knowledge capture. This process will apply to design 
verification as well as to verification of hardware and software. 

The phasing of the test and verification program is presented in Figure 7-3. The 
heavy outline shows the scope of the verification process, while the inner dashed line 
indicates the activities that are associated with the certification process. Certification 
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testing does not generally include activities associated with the development and 
qualification of electrical and electromechanical piece parts because these activities 
are controlled by the Electric/Electronic/Electromagnetic (EEE) parts procurement 
process and the MSFC Approved Parts List (APL). 


7.2.1 DESIGN VERIFICATION 

Design verification will demonstrate that the designs meet documented 
performance and functional requirements and will include activities directed at the 
component, assembly, and system. The design verification activities will include: 

a. Identification of LRB element and subsystem level performance and design 
requirements. 

b. Allocation of the verification method to satisfy the requirements. 

c. Definition and implementation of system, integrated systems, support 
equipment, and launch systems verification processes required to accomplish the 
design verification. 


7.2.2 HARDWARE/SOFTWARE VERIFICATION 

Verification will ensure that the LRB deliverable hardware and software, including 
support equipment, is built in accordance with released engineering, meets the 
Contract End Item (CEI) specifications, and is operable within the specified 
environmental ranges. This verification process is accomplished by inspections, 
acceptance tests, in-process tests during manufacturing and assembly, system 
functional tests, integrated acceptance tests, launch processing tests, and launch 
readiness tests. The verification process will include: 
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a. Identification of in-process test and inspection requirements that are consistent 
with the manufacturing build-up and assembly flow. 

b. Identification of LRB component, assembly, and system level acceptance 
requirements. 

c. Identification of all interfaces and development of the requirements that must be 
verified subsequent to component, assembly ,and system level deliveries. 

d. Allocation of appropriate verification methods to satisfy requirements. 

e. Definition and implementation of the specific inspections, demonstrations, 
analyses, and tests required to accomplish verification. 


7.2.3 VERIFICATION REQUIREMENTS DEVELOPMENT 

The verification methodology will be developed in parallel with the LRB design. 
The vehicle and system designs and performance objectives shall define all functions 
to be performed as well as required performance levels. Certification requirements, 
pass-fail criteria, and tolerances will be developed from the overall requirements. 
Verification requirements will be generated and assigned to ensure that the procedures 
for verification accomplishment are complete. 

The LRB Verification Plan will contain a set of guidelines and criteria which will be 
used in the establishment of verification methods and assignments. These guidelines 
and criteria will provide uniformity in methods applications, ensure that low cost 
methods are always considered, and assure that critical systems will be verified by test. 
The guidelines and criteria will be developed early in the program to ensure they are 
available during the design and the verification requirements development efforts. 
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7.2.4 VERIFICATION METHODS AND PHILOSOPHY OF APPLICATION 


The verification methods to be used on the LRB program include analysis, 
similarity, inspection, demonstration, and test. These methods are generally arranged 
in the order of flow from the beginning of hardware development to completion of flight 
testing. The degree to which a verification method or combinations of methods can be 
used will be based on the requirements. In general, the order of consideration and 
evaluation of verification methods will be to: 

a. Determine whether analysis could be used in lieu of test. 

b. Determine whether tests required for other purposes, such as acceptance tests, 
might be used in lieu of an additional special purpose test. 

c. Define necessary analyses, inspections, demonstrations, and tests. 


7.2.4. 1 Analysis 

Verification based on analysis, in lieu of testing or to support testing, will be 
implemented through methods such as engineering analysis, historical data 
extrapolation, math modeling, simulation, statistical evaluation, and prediction. Flight 
test demonstration will be limited to nominal flight conditions and verification of 
boundary and off-nominal conditions will be performed through analysis. 


7.2.4.2 Similarity 

Verification by similarity is the process of using the qualification documentation of 
an identical item that has been qualified for a similar application. We will use based on 
similarity (BOS) verification methods where it can be shown that the article under 
consideration is similar or identical in design, manufacturing, quality control processes, 
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and use, to another article that has been certified previously to equivalent or more 
stringent criteria. Previous certifications will be thouroughly investigated. If it is 
determined that previous certifications were not at least as stringent as LRB 
requirements we will perform additional certification in the areas of new or increased 
requirements by one of the four other verification methods. 


7.2.4.3 Inspection 

Inspection shall be accomplished by review of applicable documents, 
specifications, drawings, and/or examination of hardware for compliance with 
requirements such as construction features, workmanship, quality, and dimensional 
requirements. 


7.2.4.4 Demonstration 

Demonstration is a verification method involving the use of mock-ups, displays, or 
other devices to show operation under actual or simulated conditions. 


7.2.4.5 Test 

Testing will be performed to provide quantitative data for performance verification 
of equipment under various specified environmental conditions. The evaluation of the 
test results will determine whether or not the element or system complies with the 
requirements. We will always employ the test method for critical systems, and it will be 
the method assigned as the verification method whenever a simpler, lower cost method 
is considered inadequate from the standpoint of technical risk. All tests will be 
identified in an Integrated Test Plan (ITP). Test plans, procedures, and reports will be 
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approved by NASA/MSFC. The various types of tests that will be conducted during the 
LRB program are as follows: 

a. Development Tests. These tests (Table 7-1) are engineering evaluations 
conducted to minimize technical risk, schedule impacts, or cost, and to support design 
and analysis. Development tests are not normally subject to the rigor and controls 
associated with the qualification process. They encompass material selection, failure 
modes and effects, performance, design tolerance, and identification of operational and 
maintainability characteristics and procedures. In cases where development tests are 
required for qualification, the intent will be declared prior to such tests and the 
necessary rigors and controls will be defined and implemented to ensure validation of 
the tests and data for the qualification process. 

b. Qualification Tests. Where certification requirements cannot be met by analysis, 
BOS, inspection, or demonstration, one of the various test methods will be applied. 
Qualification tests are those tests conducted as part of the verification process to certify 
the design and to assure that the manufacturing process successfully creates products 
that meet requirements with adequate margins of safety and performance. These tests 
are conducted in accordance with formal test procedures and are covered by quality 
assurance procedures. 

Qualification units shall be flight configuration hardware, except as modified to 
accommodate minor changes that may be necessary to conduct the test. Minor 
changes may be made to the hardware for test purposes, such as the inclusion of 
accelerometers, monitoring leads, strain guages, or thermocouples. The qualification 
item shall successfully complete acceptance testing prior to the start of the qualification 
test sequence. A functional proof cycle wil be performed after every major 
environmental test to ensure functional performance. Where incipient failures, wear, or 
untestable redundant paths are involved, we will provide, as a part of the qualification 
test plan/procedure, a post-disassembly inspection to provide the necessary 
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Table 7 - 1 . LRB development tests (Preliminary list). 
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LRB DEVELOPMENT TESTS (L02/LH2) 
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LRB DEVELOPMENT TESTS (L02/LH2) 


o 



z 

o 

—1 — 1 _J _J 

-J —I -J _J 

_J _J _J _l _J _l 

_J _J _J _J _| H 

5 

co co co 55 

CO CO CO CO 

CO CO CO CO CO CO 

co co co <5 w £ 

DC 

c c c c 

c c c c 

c c c c c c 

c c c c c 

3 

© © © « 

© © © © 

©©©©©© 

©©©©©!= 

O 

£ *“< ^ 
c c c c 

^ *£ 

c c c c 


.ts ^ .ti .*= 5 

c c c c c 2 

& 

D D Z> D 

3 3 D D 

333333 


2! 

H-l—h-h- 

h h h h 

h- H~ h— H" 1“ H* 

h h h h* H 5 

o 

, UJ LU LU LU 

LU LU LU LU 

. LU UJ LU LU LU UJ 

LU LU LU LU LU £ 

o 

* Q Q Q Q 

1 Q Q Q Q 

1 Q O Q Q O Q 

1 Q Q O O Q CD 


(/) 


H 

(/) 

LU 


e 

® 

to 

£ 


V) 

O 

2 

o 

S 




^ ® § fl r O 

*c p c C £ 
© © £ C © O 


© 

<D 

© 

*3 

© 

m 


© 

l 

Q-5* 

It 

5 = 

< 3 

« 5 

o o 

•a s 

si 
8 1 
Q 


? 


OT 

© *o 


ffi 


© 
$ 
3 £ 


«c W ® 6P £ 

OqujCT © < m o q 


w S 

S 2 
* § 
© 
Jr © 
© ±r 

© 5 

° 1 


m g 


LU 


C 

Q. 

e 

5 


7-1 IB 



LHB DEVELOPMENT TESTS (L02/LH2) 
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verification information. 


c. Acceptance Tests. These tests will be conducted in accordance with formal 
procedures, with full quality assurance coverage. Acceptance tests include 
performance demonstrations and environmental exposures to screen out 
manufacturing defects, workmanship errors, incipient failures, and other performance 
anomalies not readily detectable by inspection techniques or ambient functional tests. 
The test data will be approved by our quality assurance, test agency, and design 
engineering functions prior to acceptance of hardware or software. Upon satisfactory 
completion of the acceptance tests, the cognizant project office will conduct a final 
acceptance review and will take delivery of the completed item as noted on the 
DD-250. 

d. Systems Integration Tests. Systems integration testing encompasses 
component, system, and integrated systems verification. Systems integration tests are 
conducted in a sequence that verifies components and systems individually, 
subsequently bringing these components and systems on line to verify total integrated 
systems performance. When completed, component and system level testing provide a 
verification of performance and interfaces of a particular element as it is integrated into 
the total LRB system. These tests are intended to verify fit, function, and total 
performance as higher levels of integration are achieved. The final test of the 
integrated systems verifies that all of the LRB systems perform their functions 
satisfactorily in the total integrated environment. 

A preliminary list of special tests under consideration for the LRB program is 
contained in Table 7-2. 
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7.2.4.6 Prelaunch Operations 

Prelaunch operations verify the vehicle interfaces with the ground support 
systems, the ability to tank and de-tank, interfaces with the other elements to be 
launched, and culminate in the Flight Readiness Review. Prelaunch operations 
include the tanking and de-tanking tests, dry countdown demonstration test (CDDT), 
wet CDDT, flight readiness firing (FRF), instrumentation system performance, and other 
aspects of launch readiness. These tests are conducted by the KSC launch team with 
both contractor and NASA/MSFC support. Satisfactory completion of all pre-launch 
verification requirements will be required before a decision is made to launch. 


7.2.4.7 Flight Performance 

Verification of LRB flight performance is the ultimate goal of the Verification Plan. 
The LRB will be equipped with the appropriate development flight instrumentation to 
monitor and verify performance of all systems, the severity of the environments to which 
the vehicle was qualified, and to assure that LRB capabilities meet the design 
requirements. The flight performance shall be measured by compliance with flight 
parameters and procedures developed by NASA with support from the contractor. The 
recommended approach to flight test is described in Section 9 of this Implementation 
Plan. 


7.2.5 RESULTS EVALUATION 

The results of all verification activities will be evaluated against the performance 
criteria established prior to the verification process. Only after this evaluation confirms 
satisfactory vehicle performance will the verification requirement have been satisfied. 
Verification results will be evaluated against various tolerance levels. The tightest 
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tolerances will be placed on the manufacturer's acceptance tests for LRB components. 
For systems tests, acceptable performance margins will be broadened, and during 
pre-launch tests margins will be widened further to actual flight levels. The method to 
be used to determine tolerance buildup will be the root sum square technique. 


7.2.6 VERIFICATION COMPLETION 

Verification will be documented in a formal manner. The total verification process 
documentation will provide for design knowledge capture and complete traceability of 
requirements, methods, and data to support subsequent change activities. A sample of 
the document flow for the verification process is shown in Figure 7-4. 


7.2.7 VERIFICATION CLOSEOUT 

A verification matrix will identify each requirement and specify which verification 
method will be used to satisfy the requirement. It willll identify the applicable test plan 
paragraph where verification by test is used and be used as an audit tool for closeout 
activity to ensure verification process completion. A verification report will indicate the 
test reports and analysis reports that satisfy the verification requirements and will 
specify action required to close out unresolved tasks. 


7.2.8 CUSTOMER VERIFICATION CLOSEOUT 

Customer verification reviews shall begin early in the program and will be 
conducted periodically throughout the program to ensure agreement between the 
customer and prime contractor. NASA/ MSFC will approve verified items and issue 
discrepancy reports in deficient areas of the verification process. 
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8 

LAUNCH OPERATIONS 


8.1 INTRODUCTION 

There will be three major tasks associated with LRB ground operations: LRB 
checkout and flight certification, vehicle integration, and integrated Shuttle vehicle 
checkout and launch operations. To accomplish these operations, the existing Shuttle 
on-line launch facilities must be modified to accommodate the LRB. The facility 
modifications and start-up of LRB operations must be achieved with minimal impact on 
the ongoing Space Transportation System operations. 


8.1.1 LRB CHECKOUT AND FLIGHT CERTIFICATION 

Before the LRBs can be integrated with the Orbiter and ET, they must be certified 
for flight and fully checked to verify system integrity and compatibility. 

To achieve maximum efficiency, it will be desirable to assemble the LRB in the 
vicinity of KSC, either on or off site. This approach would enable both final vehicle 
checkout and flight certification to be performed at the assembly site prior to shipment 
to the Vehicle Assembly Building (VAB) for integration with the STS. To properly 
record the flight certification of the vehicle, a documentation system that meets all KSC 
and MSFC requirements must be established. This system should be developed 
through working group meetings with the appropriate NASA personnel as shown in 
Figure 8-1 . * 

After final assembly of the LRBs, the boosters will be checked out and flight 
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certified at the assembly site (Figure 8-2). The checkout and flight certification will be to 
a level which complies with NASA STS requirements. The testing will also consist of 
compatibility tests with Launch Processing System (LPS) and the Orbiter. This will be 
done by either connecting directly into the LPS or using a LPS/Orbiter emulator that 
permits verification without requiring access to the LPS itself. 

The test firing of the engines will take place at the National Space Technology 
Laboratories (NSTL) in Mississippi. If the engines are tested in the same manner as 
the SSMEs, they will be fired prior to assembly and then shipped to the assembly plant 
near KSC for integration. If certification requirements dictate that the engines be fired 
after integration with the LRB stage, then the LRBs will be assembled at KSC and 
shipped to NSTL fortesting (Figure 8-3). 


NASA 


General 

Dynamics 



Figure 8-1. Off -site flight certification system. 
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Figure 8-2. LRB Assembly, Checkout, & Flight Certification 
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Figure 8-3. LRB Assembly, Checkout, & Flight Certification with Integrated Test Firing 


8.1 .2 VEHICLE INTEGRATION 

Once final checkout and flight certification have been completed, the LRB will be 
delivered to the VAB transfer aisle. If delivered to the VAB horizontally, the LRB will be 
lifted and rotated to the vertical position before being placed on the MLP holdown 
system (see Figure 8-4). The LRB will then be mated to all the appropriate systems, 
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such as data, fuel, ECS, and purge. Once the hookups are verified, the LRBs will be 
aligned and the ET mated, followed by the Orbiter mate. 



Figure 8-4. Vehicle integration 


8.1.3 INTEGRATED VEHICLE CHECKOUT AND LAUNCH OPERATIONS 

Once the system is fully integrated, there will be a Shuttle Integrated Test (SIT) to 
verify compatability and to test the fully integrated vehicle (Figure 8-5). The vehicle will 
then be transported to the launch pad, where payload integration and additional testing 
are performed. When these activities have been completed, launch operations begin. 
For the LRB this will consist of ordnance arming, battery installation, and fueling. If 
RP-1 is used as the primary fuel for the LRB, the vehicle will be fueled prior to or early 
in the terminal countdown. If LH2 is utilized, both LH2 and L02 will be loaded in 
conjunction with the ET tanking near the end of the terminal countdown. 
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Figure 8-5. Launch pad operations 


8.2 SCOPE 

This section describes the effort required to activate and prepare KSC for 
processing the LRBs as described above. The implementation of LRB capability at 
KSC can be grouped into three broad phases: 1) modifications and additions to 
existing KSC facilities, launch support equipment (LSE), and ground support 
equipment (GSE); 2) modifications and additions to the KSC operations support 
system; 3) verification and validation of the entire KSC system prior to the first STS 
flight with LRBs. 


8.2.1 FACILITY, LSE, AND GSE MODIFICATIONS 

The existing launch processing facilities must be modified, as summarized in 
Table 8-1, to accommodate the greater size of the LRBs and to provide a propellant 
servicing capability at the launch pads. The principal facilities that must be modified 
are the Mobile Launch Platform (MLP), launch pad, Vehicle Assembly Building, LRB 


8-5 




Checkout Facility, and the Launch Processing System (LPS). 


Table 8-1. KSC facility modifications. 



L02/LH2 
New Pump-Fed 
5A 

L02/RP-1 
New Pump-Fed 
5D 

L02/RP-1 

New Pressure-Fed 
IB 

VAB 




Platforms 

New 

New 

New 

MLP 




Propellant Service 

Tee off ET L02 & LH2 

Tee off ET L02 sys, 

Tee off ET L02 Sys, 

sys, new control skids 

new control skids 

new control skids 

Vent Mast (East) 

New LH2 

new RP-1 system 

new RP-1 system 

Launch Pad 




ETGOX Vent Arm 

New 

— 

New 

ETGH2 Vent Arm 

New 

— 

New 

Prop Store & Transfer 

Existing LH2 & L02, 

Existing L02, 

Existing L02, 


may add LH2 storage 

activate Apollo RP-1 

activate Apollo RP-1 

Launch Processing 

Modify Prop Loading, 

Modify L02 load, term 

Modify L02 load, term 

System 

Term Count.New C/0 

count. New C/O & RP-1 

count. New C/O & RP-1 

S/WandH/W 

S/WandH/W 

S/WandH/W 


8.2.1. 1 Mobile Launch Platform 

Owing to the planned high usage of the existing MLPs and the scope of the MLP 
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modifications required to accommodate LRBs, at least one new MLP will have to be 
built to support the LRB program. To minimize cost and schedule impacts, the basic 
existing MLP structural and dimensional design will be used as much as possible, and 
modified only as required for the LRB. Major MLP modifications required will include: a 
new propellant system, a new holddown system to provide a soft release for the STS, 
and enlarged flame holes for the larger LRB engine plumes. A key issue is whether to 
meet peak LRB flight rates solely by modifying an existing MLP or to build additional 
MLP units. We recommend deferring this decision until later in the program, when 
more detailed assessments of MLP usage, LRB design, and launch requirements can 
be made. 


8.2.1. 2 Launch Pad 

The principal change to the launch pad will be the installation of new propellant 
storage and transfer systems. At this early stage of the program, three propellant 
combinations are still under consideration: oxygen/hydrogen (L02/LH2), oxygen/RPI 
(L02/RP-1), and oxygen/methane (L02/CH4). Since all three LRB configurations 
utilize L02, we recommend tapping into the existing L02 transfer system in the MLP, 
which is currently used to fuel the ET. This will require an L02 propellant control skid in 
the MLP for each booster, LRB tanking control software in the Launch Processing 
System (LPS), Hardware Interface Modules (HIM) in the MLP to connect the control 
skids to the LPS, data interconnects between the firing room and the MLP, and a data 
and command interface between the LPS and each LRB booster. 

Our baseline concept for the LH2-fueled LRB configuration is to tap into the 
existing ET hydrogen transfer system in the MLP, similar to the L02 system described 
above. However, the existing capacity of the pad hydrogen storage tank will be 
insufficient to support both the ET and two LRBs. If additional storage is required, our 
recommendation is to add storage capacity but continue to utilize the existing 
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cross-country transfer system. Using the existing transfer lines will significantly reduce 
the total system boiloff losses by having to chill down only one transfer system. A vent 
system to carry the GH2 boiloff from the LRBs to the hydrogen burn stack must be 
provided on the pad. 

RP-1 cross-country transfer piping from the Apollo program still exists at both 
pads, but has not been used for over a decade and would have to be renovated, 
cleaned, and certified for LRB operations. RP-1 storage tanks exist on pad LC-39A, 
while pad LC-39B will require a new storage tanks. An RP-1 servicing capability must 
be added to the MLP to provide a connection from the pad RP-1 system and the LRB 
fuel interface. A control skid with the proper LPS software and HIMs will be required, 
similar to the L02 system. 

If methane (CH4) is used, a completely new fuel storage, transfer, LPS control, 
and MLP servicing capability must be added. 

In addition to the propellant storage and transfer systems described above, the 
launch pads will also require other modifications, which will vary depending on the final 
LRB configuration chosen. Because the LRBs using hydrogen, pressure-fed RP-1 , and 
methane are significantly longer than the present SRBs, the LRB tanks would interfere 
with the ET GOX vent arm, which presently extends over the left-hand SRB during 
pre-launch pad operations. If any of these LRB configurations are selected, this vent 
arm will have to be modified in a manner that it will enable it to "wrap around" the LRB. 
If the LRB diameter exceeds 14 feet, as is the case for some of the concepts currently 
under consideration, the LRB will also interfere with the existing ET hydrogen vent arm, 
which attaches to the ET in the intertank area. Selecting the LH2 or pressure-fed LRB 
will require a modification to the vent arm to preclude interference and provide suitable 
launch clearances. This change may also require changing the hydrogen vent location 
on the ET. 
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8.2.1. 3 Vehicle Assembly Building (VAB) 


Integration of the STS flight elements is presently done in Highbays 1 and 3 of the 
VAB by stacking the SRBs on the MLP, mating the ET to the SRBs, and connecting the 
Orbiter to the ET. During this integration process, access to the STS elements and the 
completed STS stack is provided by movable work platforms which extend to enclose 
the entire STS. Because these platforms are designed specifically for the STS with 
SRBs, the different dimensions of the LRBs will require modification to the platforms. 
The platforms will have to be modified to accommodate the larger diameter LRB. The 
"flip-up" dimensions will also have to be changed to permit the STS with the larger 
LRBs to pass by as the STS exits the VAB. In addition, the upper level platform, which 
now fits around the ET, will have to be changed to fit around the longer LRBs as well as 
theET. 


8.2.1. 4 LRB Checkout Facility 

Accommodations for final checkout and flight certification for the LRBs must be 
provided at KSC. If the LRBs are to be delivered completely assembled from a distant 
location, a temporary storage and checkout capability will be needed. This would 
require facilities with access to LPS or an LPS emulation checkout test set and 
sufficient space for checkout equipment. If the LRB final assembly facility is built at 
KSC, the checkout and flight certification capability can be designed into the new 
facility, thereby adding efficiency to the ground processing of the LRBs. 


8.2.1. 5 Launch Processing System 

The addition of the propellant systems at the launch pads described above will 
require new LPS software and interface hardware, including launch consoles, to 
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provide control and monitoring of the ground propellant systems and to interface with 
the LRBs to control and interact with their on-board systems during propellant loading. 
Additional LPS software and hardware will also be required to control and interact with 
the LRB during all other ground checkout and integrated operations, including final 
countdown and launch. 


8.2.2 OPERATIONS SUPPORT 

In addition to the hardware and software changes already described, another 
major element in implementing the LRB launch capability will be to develop and 
maintain the operations support system. One of the primary tasks will be the 
development of new or modified Operations and Maintenance Instructions (OMI) to 
provide procedures for all the LRB related ground processing. Included will be 
stand-alone LRB checkout and modified OMIs for the integrated processing tasks that 
will be changed for LRB compatibility. The launch crew that will process the LRBs must 
be trained and certified prior to processing the first flight LRBs. 


8.2.3 VERIFICATION AND VALIDATION 

The final phase of the KSC activation process will be to verify and validate all 
changes. This will begin with such tasks as validation of the LRB L02 systems that tee 
off the existing ET L02 systems, and will conclude with the last validation test for the 
STS/LRB system: the Flight Readiness Firing (FRF), involving a normal STS 
countdown and firing of all Orbiter and LRB engines, but inhibiting STS release. This 
test will validate that the ground and flight systems play together properly up to liftoff 
and will validate all of the STS systems. 
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8.3 APPROACH 


Because the LRBs will be Shuttle elements, the primary responsibility for integrating 
the LRBs into the STS ground processing system will normally reside with KSC, with 
major support from Marshall Space Flight Center and the LRB contractor. This section 
describes the approach that GDSS will take to insure proper support to KSC. 


8.3.1 MODIFICATION PHASE 

The primary responsibility of the LRB contractor during the KSC modification 
phase will be to provide timely LRB ground processing and GSE and facility 
requirements to KSC, so that the launch site preparations can be accomplished to 
support the initial LRB processing. The first step in establishing the requirements will 
be to develop a functional ground flow to depict each major element in the LRB ground 
processing, such as receipt, inspection, checkout, terminal countdown and launch. For 
each of these functional elements, GDSS will define the LRB support requirements and 
KSC will define the KSC requirements, such as safety. From these requirements, the 
details of the functional flows can be defined, GSE and LSE design specifications can 
be developed, and any required changes to the GSE, LSE, or LRB can be identified 
early in the development process. 

To accomplish the above tasks, a great deal of requirements information must flow 
freely between MSFC and its LRB contractor and KSC and its contractors. A primary 
vehicle for transmitting these data wiill be working groups, chaired by one or more of 
the NASA centers and involving the appropriate STS and LRB contractors. It is 
expected that working groups will be established to address such subjects as Ground 
Operations, Countdown, Fluids, and Avionics. The working groups will allow free flow 
of technical data between the responsible engineers, assignment of action items, and 
agreement on issues common to several STS elements, such as L02 flow rates to 
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each of the LRBs. Table 8-2 shows the likely division of responsibilities for launch site 
modifications. 


Table 8-2. Likely division of responsibilities for launch site modifications. 


Kennedy 

Space 

Center 

• Design and construct new MLP 

• Design and build all integrated processing GSE permanently 

installed at KSC 

• Design and accomplish facility modifications 

• Design, acquire & install LSE 

• Develop LPS software 

• Establish and maintain LRB OMRSD 

• Develop and modify OMIs 

Marshall 

Space 

Flight 

Center/ 

LRB 

Contractor 

• Provide LRB requirements for GSE, LSE, facilities, & operations 

• Develop on-board checkout/launch systems compatible 
with KSC ground systems 

• Design & build transportation, handling, off-line checkout, & 
maintenance GSE 


8.3.2 VERIFICATION AND VALIDATION 

Prior to processing a flight vehicle through KSC, the modifications to KSC 
facilities, hardware, software, and support systems must be validated. To verify the 
physical interfaces and clearances, GDSS will provide two LRB pathfinder vehicles 
which will have the same physical dimensions and interfaces as the flight vehicles. 
The pathfinder LRBs will be processed through the KSC facilities using the preliminary 
OMIs developed by KSC from the LRB requirements and will serve to identify any 
incompatibilities between the facilities, the GSE, the LRB or the OMIs. During this 
process, GDSS will provide an engineering team to resolve and approve any required 
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changes. 


Our approach to verification will be to first conduct functional tests of individual 
components and to progress logically to total integrated system checkout. An example 
is our approach to verifying the liquid propellant storage, loading, and drain capability 
and the required propellant system controls, one of the principal areas of change 
required to accommodate the LRBs at KSC. After testing the components in the 
propellant transfer systems, we will conduct a cold flow test — flowing L02 from the 
storage tanks through the existing transfer system to the MLP and through the two new 
LRB "tees," to ensure that all hardware and software interact and control the flow 
properly. Finally, the ET and the LRBs will be loaded with propellants using the 
hardware, software, OMIs and launch crews as a final validation of the propellant 
systems. 

All of these tests will use the new hardware and be controlled by the new LPS and 
LRB software. Because the LPS and LRB control software and the data exchange 
between the two is so critical to safe propellent loading, GDSS will provide an LRB 
Avionics Simulator to validate the systems prior to the ET/LRB tanking. Throughout the 
process of validating KSC implementation, GDSS will provide an engineering and 
operations support team at KSC. The team will have the engineering expertise and 
authority to approve all engineering and operational changes required to ensure full 
compatibility between the KSC and LRB systems. 


8.4 LAUNCH OPERATIONS INTEGRATION 

KSC will develop and maintain Interface Control Drawings for all of the LRB facility 
interfaces. The ICDs will be reviewed by a NASA working group, consisting of KSC 
and its contractors, MSFC, and its LRB contractor team. The primary interfaces of 
concern are actual physical connections between the LRB and facilities, physical 
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clearances between the LRB and facilities, and data exchanges between the LRB and 
the ground facilities during ground processing and launch. 
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9 

MISSION OPERATIONS SUPPORT 


9.1 SCOPE 

The LRB prime contractor will support the critical NASA functions of mission 
planning, operations, and analysis by developing LRB flight requirements and 
constraints, analyzing LRB mission performance, and by supporting NASA/MSFC and 
the STS Program in accomplishing these functions for the integrated launch vehicle. 
During the LRB flight test program, additional tasks will be required, including definition 
of flight test requirements and comprehensive analysis of mission data. Our goal is to 
establish a certified operational envelope at the end of the test program. These 
responsibilities will be carried out under the coordination of the SE&I organization and 
will include support of all LRB Project technical groups. 


9.2 MISSION PLANNING AND PREPARATION 

The LRB prime contractor will support NASA in a variety of pre-launch tasks, 
beginning with assistance in definition and implementation of the STS-LRB flight test 
program and continuing throughout the operations phase with support for Flight 
Readiness Reviews. 


9.2.1 FLIGHT TEST 

The test program currently envisioned will require four test flights of the STS-LRB 
configuration. Successful completion of these test flights will constitute final verification 
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of the LRB and of the integrated launch vehicle. Our recommended flight test program 
is based on the following: 

a. Conservative build-up of flight conditions to assure safety is not compromised 
during the initial flights. 

b. Demonstration of nominal system performance by the end of the test flight 
program. 

c. Validation of the engineering data base and analytical models for use in 
verification by analysis of the full flight envelope, including dispersed performance and 
environments as well as failure and contingency cases. 


9.2.1. 1 Flight Test Requirements 

The STS-LRB flight test program will have a number of objectives. These 
objectives will include demonstration and verification of the following key in-flight 
capabilities: 

a. Compatibility of the LRB with other STS elements. 

b. Achievement of mission performance capability. 

c. Ability to provide specified thrust time histories. 

d. Achievement of nominal performance of all LRB subsystems in the flight 
environment. 

e. Verification of induced structural and thermal environments. 

f. Safe LRB separation. 

These primary objectives will be expanded to detailed requirements through 
analysis by experienced test engineers in the Test and Evaluation group. This activity 
will include definition of test techniques and instrumentation, data analysis and 
analytical tools required, and data required from other program elements. This will be 
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documented in a preliminary LRB Flight Test Plan that will be coordinated with NASA to 
develop the integrated flight test plan including the approach for build-up of flight 
conditions. Final requirements will be documented as Flight Test Objectives for 
assignment to specific missions. 


9.2.1. 2 Flight Envelope Expansion 

Initial LRB flights will be planned in a conservative build-up of flight conditions to 
provide maximum practical protection against unanticipated events or conditions. The 
specific strategy for achieving this build-up will be developed thirough analysis of 
system margins for the LRB as well as for other elements of the integrated launch 
vehicle. This build-up could include such features as a reduction in performance 
requirements to protect against dispersions and to provide extra margin to allow 
shaping the trajectory to reduce critical loads and system stresses. Additional 
limitations on environmental conditions such as winds, ground ambient temperature, 
and moisture might also be imposed. 


9.2.1. 3 Flight Test Analysis and Reporting 

Detailed analysis of data from the four test flights will confirm the safety and 
performance of the LRB and of the integrated launch vehicle. The General Dynamics 
LRB project office will perform this analysis for the LRB and all LRB subsystems, using 
data from the Orbiter Operational Instrumentation downlink as well as from the 
Development Flight Instrumentation (described further in Section 9.2.1. 4). If applicable, 
recovered flight hardware will be inspected as part of our test analysis. 
Comprehensive mission reports will be submitted to NASA/MSFC covering all aspects 
of LRB subsystem and interface performance. To the greatest extent possible, 
analytical tools required for this analysis will be developed and proven during ground 
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tests. 


A major part of mission analysis will involve element interfaces and integrated 
launch vehicle performance and induced environments. Existing analytical tools 
developed by NASA/MSFC and Shuttle System Integration, and proven on previous 
STS flights, will be used to provide this data. General Dynamics will support NASA in 
determining modifications necessary to these tools for analysis of the vehicle with 
LRBs. The LRB prime contractor will also participate with NASA and its contractors in 
analysis of integrated launch vehicle performance and interface conditions, including 
interpretation of LRB performance and conditions. 

Another major requirement for analysis will be the establishment of a database for 
validation of system math models, both for the LRB and for the integrated launch 
vehicle. In many cases this will be the most demanding requirement for establishing 
analysis plans. 


9.2.1 .4 Flight Test Instrumentation 

It is anticipated that a Development Flight Instrumentation System (DFI) will be 
installed on each LRB. These systems will be used during the test flights to supplement 
operational data from the Orbiter Operational Instrumentation (01) downlink and will be 
time-synchronized to that system for data correlation. Features of the DFI will include: 

a. Strain gauges, accelerometers, and pressure transducers to determine 
structural loads. 

b. Microphones to determine acoustic environments at selected locations. 

c. Temperature measurements to determine the thermal environments of selected 
structural subsystem elements. 

d. Other required information not provided via the Ol. 
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9.2.2 MISSION DESIGN 


Effective mission planning will require integration of the capabilities and 
constraints of all STS-LRB elements. A basic objective of LRB development is to 
maintain compatibility with existing integrated launch vehicle constraints, thus 
preserving the base of knowledge developed in previous STS flights. General 
Dynamics will support NASA mission planning and design activities by providing a 
comprehensive definition of LRB requirements and constraints, tailored to mission 
design and operations, and by supporting NASA in defining and verifying modifications 
to existing operational tools such as the Abort Region Determinator. General Dynamics 
will also assess mission plans for LRB compatibility. 


9.2.2.1 LRB Mission Capabilities and Constraints 

As stated in Section 9.2.1 , our objective is to establish a verified operational 
envelope for the LRB subsequent to the flight test program. Accomplishing this and 
documenting it in a controlled, usable form, will facilitate NASA’s mission planning and 
reduce LRB project support required for mission preparation. Because many LRB 
conditions are derived from integrated launch vehicle effects, it will be necessary to 
accomplish this in conjunction with NASA. 

We expect to work with NASA through the existing Systems Integration Review 
panel structure to allow definition of critical parameters and the optimum form for their 
use. Similar coordination of ground and flight test results will allow development of 
LRB and integrated launch vehicle capabilities and constraints. The increased 
complexity, capabilities, and alternatives to flight operations will require new flight rules 
and procedures to be developed and carefully evaluated, including updates to the 
launch commit criteria. In conjunction with the new flight rules and procedures, new 
software must be developed, tested, and certified to reflect these changes. After 
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approval by NASA, these will be placed under strict configuration control. 


9. 2.2.2 Mission Design Support 

As specific missions are defined, support will be provided in flight 
design/procedures development, software reconfiguration/certification, and training 
and simulations. Each area will be reviewed for compatibility with LRB limitations and 
capabilities and modified accordingly. 

Exceedances, low margin conditions, and unverified conditions will be studied as 
appropriate. Such studies will be conducted with other program elements as 
appropriate, such as to see if the addition of LRB throttling capability and the possibililty 
of different LRB thrust profiles change the area over which the external tank operates. 

It is anticipated that efficient mission design will require "tag" values to define 
performance of the specific hardware end items assigned to each flight. Parameters 
such as engine thrust and specific impulse, defined from engine acceptance tests, 
could provide more accurate planning data than specification values. It is assumed 
that the LRB liftoff and ascent loads environment for the payloads is the within the same 
envelope as the present system, and therefore should be transparent to the payloads 
community. 

In conjuction with the modified flight rules and procedures, software must will need 
to be reconfigured and tested for the use in the Shuttle Avionics Integration Laboratory 
(SAIL) and Shuttle simulators. This development will be accomplished per the 
Systems Integration Schedule D. 

As new flight rules and procedures are established, training workbooks and 
simulation scenarios must be updated to reflect these changes. Flight crews and flight 
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control operators will be trained in the new ascent procedures required by the the more 
complex LRB control functions. 


9.2.3 MISSION ASSESSMENT 

As specific missions are defined, the LRB project office will conduct a 
comprehensive assessment of the capability of assigned LRB hardware to meet 
mission requirements. This will be accomplished in three parts, as follows: 

a. Performance and Environment - Data provided by the System Integration 
Contractor will define the trajectory parameters including LRB performance 
requirements and the induced environment. These data will be used to assess 
structural loadings, thermal environments, separation conditions, and other critical 
parameters for both nominal and abort conditions. Flight margins will be defined for 
each parameter. Support to NASA for day of launch commit-to-flight decisions requires 
the development of "load indicators" that reliably reflect the effect of measured wind 
profiles on critical structural elements. Real time mission support will be required to 
evaluate results of this analysis. 

b. Avionics Interfaces - Participation in planning, conduct, and review of data from 
NASA's Shuttle Avionics Integration Laboratory (SAIL) will provide assurance of the 
hardware and software interfaces in the simulated mission environment. 

c. Ground Operations - Review of the planned LRB ground operations at KSC will 
be conducted to identify and assess any unique activities or interfaces that are 
expected. 
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9.2.4 FLIGHT READINESS REVIEW 


The LRB project office will support NASA's objectives of assuring mission success 
and safety by conducting a comprehensive grass-roots Flight Readiness Review (FRR). 
The internal LRB project FRR will utilize informal working meetings within each 
organization to assess readiness for flight. These informal meetings will be followed by 
a Project Review, chaired by the project manager, in which each organization will 
report on readiness for their assigned area of responsibility and submit Certifications of 
Flight Readiness. A corporate review board will conduct an independent summary 
review after completion of the Project Review. It is expected that NASA will participate 
in both the project and corporate summary reviews. 

After completion of the corporate review, General Dynamics will support the NASA 
FRR activities by providing data packages and summary briefings that address the 
following: 

a. Results of the Mission Assessment described in Section 9.2.3, to assure 
compatibility of the assigned hardware with the mission requirements and environment. 

b. Review of test and assembly records to identify anomalies and corrective 
actions to assure integrity of the assigned hardware. 

c. Review of the as-built versus as-designed hardware to assure the assigned 
hardware conforms to the documented, verified design. 

d. Review of all configuration changes since the previous flight to understand 
possible impact on system performance and ground and flight operations. 

e. Readiness of the operations team assigned to support ground and flight 
operations. 
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9.3 MISSION ANALYSIS 


After completion of the flight test program, our post flight analysis will be reduced 
in scope. Data received from the Orbiter Operational Instrumentation downlink will be 
analyzed to accomplish the following: 

a. Verification of LRB system performance within normal limits. 

b. Identification and investigation of anomalies. 

c. Verification that LRB interfaces and induced environment conditions are within 
documented limits. We will support NASA as needed in the investigation of 
unexpected or out of tolerance conditions. 

d. Support to NASA in analysis of integrated launch vehicle performance, to 
define LRB characteristics utilized in system dispersion analyses. 

Mission summary reports will be developed for each flight. 
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SECTION I 


1.0 INTRODUCTION 

In Section 8 of the Implementation Plan some of the requirements to activate and prepare 
KSC for processing the LRB's are identified and discussed. This transition plan is an expansion of 
those ideas and how they will be accomplished, phased-in, and integrated to assure that manpower, 
facilities, and equipment are in place at the right time to support first LRB launch. 

1 . 1 Background - A principal LRB program goal is to develop the flight vehicle concurrently 
with preparation of the KSC launch facilities for the flight test program. Accomplishing this goal 
will depend on timely management decisions to identify flight vehicle configuration, payload 
weights, and mission profiles. Once these key decisions have been made the launch site transition 
can proceed. KSC has traditionally been responsible for all transition activities at the launch site. 

1.2 Objective - The objective of this transition plan is to provide guidance to management and 
implementers alike so that coherent decisions can be made, and coordinated use of resources can be 
exercised to achieve the desired goals. Further, it is an objective of the transition plan to facilitate 
the most economic expenditure of funds and still maintain the highest standards of safety, quality, 
and efficiency during the modification, acquisition, and flight test phases of the transition. 

SECTION n 


2.0 SCOPE 

This plan describes the actions necessary to establish an LRB launch capability at KSC and 
support the flight test program. It does not cover actions at the manufacturer's facilities, NSTL, 
MFSC, or movement of the LRB to KSC. 

2.1 Requirements - The primary requirement is to transition KSC capability to launch the 
LRB/STS while at the same time continuing the SRB/STS program without slowdown until the 
LRB/STS is able to cany scheduled payloads into space. Actions to accomplish this can be 
grouped as follows: 

a. Modifications and additions to existing KSC facilities. 

b. Modifications or additions to existing KSC launch support equipment (LSE) and ground 
support equipment (GSE). 
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c. Modifications and additions to the KSC operations support systems (ie; manpower, 
training, logistics, software, etc). 

d. Verification and validation of all changes and/or additions to assure compatibility with 
existing systems and operations, to comply with all NASA safety and product assurance criteria, 
and to complete necessary confidence-building demonstrations. 

2.2 Schedule Constraints - The transition of KSC capability to launch LRB's is constrained at the 
outset and at the finish by the flight article development schedule. Figure 2-1 is a master schedule 
of the major categories of KSC transition activity leading to first launch. 
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LRB TRANSITION MASTER SCHEDULE 
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SECTION UI 


3.0 APPROACH 

Although the pacing factor in the LRB program is usually thought to be the development of 
the flight article, any delay in initiation of transition activity at KSC could impact the planned first 
flight date. GDSS will participate in a timely information exchange with NASA and its contractors 
so that design specifications will be readily available for facility and equipment modification or 
acquisition. Management and execution of the transition activities at KSC is a KSC responsibility. 
The approach taken herein is to describe what must be done and how to do it without specifically 
designating who will accomplish the individual tasks. Delegation and performance of necessary 
work will be in accordance with program and contracting decisions. Each major category of 
activity will have its timelines and milestones to facilitate integration. 

3.1 LRB Interface with SRB/STS - Throughout the LRB transition period at KSC, modifications 
to facilities and/or equipment in place or the addition of new equipment will require that whoever is 
performing the transition tasks be ever aware of the on-going Shuttle launch program. Any place 
where there is an interface between LRB and SRB activities due care must be exercised to assure 
the dual-flow nature of the two programs being conducted simultaneously. This is especially true 
on the pad during pre-launch processing and countdown. For example, fail-safe devices and 
procedures must be included to make it impossible for the wrong software to be used in the LPS. 
Strict control of ICD's during the transition design phase will aid in the development of adequate 
OMRSD's for coordination with existing operations pro cedu res. OMI's must accommodate 
procedures for proper use of interchangeable equipment and facilities. Since it may be necessary to 
use the same personnel on both programs in some operations, safeguards must be developed to 
minimize the risk of human error in such a side-by-side situation. 

3.2 Facility Modifications and Acquisition - Every effort will be made to use existing facilities. 
Where modifications are required, the design activities will consider the dual-use (ie; SRB/STS and 
LRB/STS) requirements, where possible, and include "murphy-proof and fail-safe interfaces. 
Since the SRB/STS launch schedule will require the use of the three existing mobile launch 
platforms (MLP), design and acquisition of a fourth MLP will be required to support the flight test 
program. Modifications to the VAB, Launch Pads, and LCC will require careful scheduling to 
allow for on-going operations. Following are descriptions of concepts and some "how-to" 
solutions for getting the job done. 
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3.2.1 Mobile Launch Platform - The mobile launch platforms (MLP) currently supporting the STS 
with Solid Rocket Boosters (SRB's) are modified Saturn Launcher/Umbilical Towers (LUT) that 
have been in service for more than twenty years. Major modifications were made to satisfy the 
Space Shuttle requirements. Modifications included were: 

a. Removal of the umbilical tower and hammerhead crane • 

b. Removal of the Saturn hold-down arms and blast shields 

c. Cutting different exhaust holes for the SRB's and the Orbiter Main Engines 

<L Installing SRB hold-down posts and Orbiter tail service masts (TSM) 

e. Installing a major modification to utilize water as a sound suppressor and coolant 

Further modification of the existing MLP’s may not be practical. The repeated heating and cooling 
of the MLP's has caused warping and cracking of the deck. Metal fatigue is not unlikely under 
these extremes of thermal and mechanical stressing and stress reversals. The major structural 
changes needed for adaptation of the MLP's to the LRB's may not be feasible from a sound 
engineering or financial viewpoint or for dual interchangeable use with both SRB's and LRB's. At 
some time during the LRB development or transition from SRB to LRB employment, a 
modification program could be initiated if further analysis shows that modification is feasible. In 
the interim, it is essential that a new MLP be designed and acquired specifically for the LRB's. 

KSC will likely proceed with design, construction, outfitting, and verifying the new MLP in a 
straightforward manner. For whoever is assigned the responsibility by contract, the first step will 
be to assure that lessons learned and technological advances available are considered in designing 
the new structure. Specific criteria will be used to retain as many existing interfaces as possible, 
and safety and efficiency will be improved. A more rigid MLP structure will be needed to 
accommodate stresses during engine thrust build-up and launch, or in the event abort on the Pad is 
necessary. 

Included in the detailed design criteria for the MLP will be the impacts of the selected LRB 
configuration such as booster size and weight, number and type of engines, chosen propellants, 
support/hold-down requirements, control/monitoring equipment and the vehicle flexibility. To 
produce the most efficient and adaptable MLP, requirements for the SRB's will not be considered if 
they compromise the design in any way, unless management directs otherwise. Development of 
the detailed design requirements will be a joint NASA/GDSS task. The MLP will be designed for 
m ax imum stiffness to help offset the normal tendency of a liquid propellant booster to be less rigid 
than a solid propellant booster. During the dynamic analyses of the integrated vehicle and potential 
operating conditions, extendable columns and soft release systems will be considered for use. 
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Action will be taken to assure that all of the NASA and NASA contractor experience (i.e. 
Reynolds, Smith, and Hills and LSOC) with design, acquisition, and use of the existing MLP's is 
incorporated into the requirement and design of the new version. 

The proven NASA acquisition process will be utilized. In addition to pertinent industry and 
government design and acquisition documents, the KSC-DE-512-SM "GUIDE FOR DESIGN 
ENGINEERING OF GROUND SUPPORT EQUIPMENT AND FACILITIES FOR USE AT 
KENNEDY SPACE CENTER" will be used. 

KSC will assure that the NASA design review process is followed, that fabrication complies with 
industry and government standards and FAR's, and that logistics engineers are integrated into the 
design process as early as possible. Quality control and inspection will be key elements in the 
design and acquisition of the MLP, from design initiation through launch. Verification will be 
performed at specific milestones in the acquisition process, with final fit check and systems 
checkouts to be performed using a pathfinder LRB/STS. 

After the basic structural design is under way, the general arrangement layout of service facilities 
(ie; additional propellant service masts, etc.) and the integrated space vehicle support equipment and 
systems will be prepared. Space will be allocated, physical locations assigned, and detailed 
plumbing and electric circuitry will be included. 

Construction and outfitting will be serial, with minimum overlap. Outfitting can be by individual 
system contractor, by an installation contractor, or perhaps the most efficient methodology will be 
to have the Launch Operations Contractor (LOC) install equipment and verify that the design 
requirements have been met. This will be done before validation that the equipped MLP meets all 
operational requirements. The result of using the LOC in this manner should result in a shorter 
learning curve and allow the LOC (presently LSOC) maximum time to gain expertise with the new 
MLP and equipment Figure 3-1 is a schedule showing the approximate time to complete the major 
events to activate a new MLP. 

If assigned to perform the design task, GDSS can call on the General Dynamics Electric Boat 
Division for assistance to take advantage of the technology available in that organization. They 
have experience in designing and building complex launch support structures, including nuclear 
powered submarines. 
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LRB NEW MLP ACQUISITION SCHEDULE 



FIGURE 3-1 






3.2. 1.1 Holddown and Release System - One of the major challenges during the design of the new 
MLP will be providing a satisfactory system to support and hold down the LRB and to effect a soft 
release for liftoff after all engines have achieved full thrust The present release system in use by 
the SRB/STS has functioned successfully for each launch. The Saturn V release system used a 
method of cold drawing metal rods to reduce shocks and vibrations resulting from suddenly 
releasing the flight vehicle after the thrust of each engine had been verified. 

Although the flexibility of the LRB's is greater than the SRB's, the simplicity and reliability of the 
present STS support and explosive bolt release system warrant consideration for use. If used, a 
square support ring will bridge the LRB flame hole and permit very short spherical bearings to 
support the booster skirt at four places (mid- way between rocket engines). Each support will be 
adjustable and have a bolt through the center of the bearing. Restraining the skirt will be a frangible 
nut containing small explosive charges. Over these nuts will be debris catchers to assure fragments 
can not escape. By having a stiff support ring and short supports above the ring, flexibiity will be 
minimized. 

Despite steps mentioned above, there remains a likelihood that the release of the tensile forces 
generated by the eight booster and three orbiter engines will allow a snap action that will produce 
adverse shocks and vibrations into the flight vehicle at liftoff. The Saturn V method of cold 
drawing metal rods can minimize these affects. Each rod can be shaped to furnish the desired 
force/distance profile, that is, maximum restraint at first motion decreasing to zero at the rods end. 
The number of rods and their profiles will be determined by detailed analysis. Several rods will be 
distributed around the booster skirts and located as near the support/holddown points as 
convenient. 

3.2. 1.2 Exhaust Holes Design and Fabrication - The original exhaust holes in the early 
Launcher/Umbilical Towers (LUT) were designed and then cold and hot flow tested as scale 
models to assure the satisfactory performance of the Saturn V vehicle, LUT and Flame trench 
combination prior to the first launch. Back pressure, base heating, and flame recirculation were 
explored to assure adverse conditions would not endanger the launch vehicle. Studies of the 
potential LUT temperatures, rocket exhaust pressures, and induced vibrations were used for 
designing, testing, and developing measurement programs to verify the design requirements were 
adequate and actual conditions were in compliance. The holddown period for engine thrust 
build-up and verification was very critical in not damaging the vehicle or LUT and equipment 
When the LUT was modified to accommodate the Shuttle it was renamed the MLP. 

The Shuttle, with the solid boosters that require no holddown except that needed during SSME 
runup, have much less potential for similar problems. Since the Orbiter/ET location and 
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relationships on the MLP are unchanged, there will be no changes to the Orbiter/SSME flame hole 
location on the MLP. 

Once the center lines of the LRB's are established in relationship to the Orbiter/ET, the design of 
the LRB flame holes can be formalized. Conflicting requirements can be resolved into the best 
compromises, however the location of the Orbiter/ET must not change. Smooth exhaust gas flow 
can be attained by having large openings and no changes in direction. Exhaust heat flux influences 
the designer to move structure away -from the exhaust flow, but sound structural design practice 
requires the supports be placed under the loads, especially if rigidity is desired. Smaller holes will 
permit a stiffer MLP. The use of existing pad flame deflector and flame trench is a design criteria. 
The LRB exhaust holes will be kept as small as convenient to allow minimum eccentric loads on the 
cantilevered haunches supporting the rigid square ring on which the flight vehicle rests. The main 
structural supports for the flight vehicle through the ring and haunches are the twenty-five foot 
girders. The flame holes will be lined with "fire box" quality sheet steel backed by insulation that 
will protect the load carrying structural members. The design criteria for the MLP exhaust holes is 
the same whether applied to a new MLP or modification of the existing ones. Water is presently 
available in large quantities at the pads, therefore sufficient water is available for cooling and sound 
suppression, if needed. 

Fabrication will necessarily be done at KSC, so a construction site must be selected that is 
accessible to the crawler-transporter and fabrication work activities, but which will not interfere 
with on-going Shuttle launch operations. If large quantities of steel are to be moved by rail, the site 
should be close to the KSC railroad system. The use of existing NASA design and review 
procedures and the application of KSC-DE-512-SM will assist in the orderly activation, testing, 
and transition of the LRB/MLP. 

3.2. 1.3 Propellant Servicing System (MLP Segment) - Launch Complex 39 has a twenty-five year 
history and has more propellant servicing capability than is now being used. The approaches 
developed and proven by time will be followed where practical in the design and implementation of 
LRB modification. The thermal protection system (TPS) on the orbiter is very sensitive to impact. 
Snow or ice denser than 14 pounds per cubic foot will possibly damage the TPS. Therefore, it is 
mandatory the cryogenic systems do not permit ice formations that could be dislodged and fall or be 
blown against the orbiter TPS. The following steps, if pursued, should facilitate the design and 
fabrication of changes necessary to accommodate the LRB servicing on the MLP: 

a. Design the MLP propellant support equipment and facility modifications using STS 
Program Documents and the KSC Design Requirements such as KSC-DE-512-SM. These 
documents will effect minimum changes to the operations and propellants systems consistent with 
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the latest technology and maximum utilization of existing hardware and software. The operator will 
be requested to participate in all phases of the design/acquisition process. 

b. Assure the NASA design review process is followed and that safety, reliability, quality, 
maintainability, and logistics engineers are involved in the development of the design from the 
preliminary phase to the Operational Readiness Inspections. 

c. Use the NSTS Launch Processing System (LPS) methods and the propellant monitoring 
and control software as guides in the development of new requirements and software. Control of 
the propellant systems will be largely from the signals furnished by point sensors on the LRB's i.e. 
at the 2%, 98%, 100% load points in each propellant tank. Software sub-routines used in checking 
flight and ground subsystems will be as identical to the LPS software as possible. 

d. Develop and enforce a plan to assure complete inspection, design verification, and testing 
are performed on the hardware and computer software, and that adequate documentation and spares 
are available to the operator at system turn-over. 

e. Involve the operator in every design/development step and invite participation in all testing 
to assure operator inputs are considered and to minimize any training requirements to achieve 
proficient operations. 

f. Verify the design and hardware of each modification or new piece of equipment that 
interfaces with or could impact the flight vehicle is qualified. The Launch Equipment Test Facility 
(LETF) will be used to prove the acceptability of each critical support item prior to installation on 
the MLP or at the Pad. Examples of items to be tested are vent arms and the propellant service 
masts. 

g. Plan to use non-flight LRB's such as structural/dynamic or propulsion test boosters as 
facility check out vehicles (or pathfinders). The Enterprise could possibly be made available to 
validate the total flow and physical and functional hardware flight vehicle to ground interfaces. 
Two test boosters are required for a "full up" series of propellant systems tests to demonstrate as 
closely as possible the capability of these systems prior to mating with and servicing the first flight 
article. 

h. Be ready to furnish sustaining engineering support throughout the life of the program. 

3.2.2 LRB Assembly and Checkout Facility - Pending the decision by LRB program management 
to adopt a "ship assembled" or "ship in segments" modus operandi, definitive planning for a facility 
at KSC for the assembly and checkout of the LRB must be postponed. If assembly and checkout 
are to be performed at KSC in existing facilities, the VAB center isle in the low bay is the only 
place where the horizontal work mode can be exercised. To use this space, it will be necessary to 
re-align the Solid Rocket Motor (SRM) processing flow. If the LRB is shipped assembled and 
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only needs checkout prior to rotation for mating on the MLP, checkout could be performed 
temporarily on the barge, or the VAB transfer isle can be used for this purpose. If a new assembly 
and checkout facility is authorized, it will be necessary to obtain funding from extraordinary 
sources since the normal Construction of Facilities (C of F) cycle will not accommodate present 
estimated schedules. 

3.2.3 Vehicle Assembly Building (VAB) Modifications - The major impact the LRB will have on 
the configuration of the VAB will result from the increased size of the LRB over the SRB, which 
will require modification of the access stands and platforms. Also, some additions and/or changes 
will be required to the electrical/electronic checkout and test equipment now in use to check out 
SRB's after stacking on the MLP. 

The following goals previously established should be observed in the planning for the design and 
implementation of modifications within the VAB. 

a. The modifications should accommodate either the SRB's or the LRB's interchangeably. 

b. The launch schedule should not be affected by the installation of the modifications. 

c. Modification work in one high bay will not impact integration effort in the adjacent bay. 

d. The Orbiter and the External Tank (ET) location and access will not be affected by any 
modification. 

The KSC/SPC-LOC have indicated a single open period may be found for modifications within the 
VAB, however, the approach should not be dependent on a schedule opening that could vanish 
because of changing launch pressures, or other unforeseen events. Figure 3-2 is a tentative 
schedule of VAB modification work. 

3.2.3. 1 Work Platforms - The VAB high bays 1 and 3 have been outfitted with access platforms 
required during the integration of the Space Shuttle using SRB's. Presently, nine levels are 
available for access to the booster, orbiter, and ET. Each will be affected when the new LRB is 
processed in the VAB. Minimum modifications likely are: 

a. The increased diameter of the LRB over the SRB requires that all nine existing work 
levels have larger cut outs. 

b. The increased LRB length will probably require additional work levels within the 
VAB to access all areas of the new boosters. 


11 



VAB MODIFICATION SCHEDULE (PRELIMINARY) 
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Removal of basic platform steel will be necessary to assure adequate safety clearances with the 
flight hardware at all levels. Cutting and welding activities would likely impact operations in the 
adjacent bay if done within the VAB. 

Whoever is selected by NASA to do this job should: 

a. Perform a cost trade study as part of the preliminary design of platforms which meet the 
requirements of both the SRB and the LRB Shuttles. Consider an adjustable filler deck system that 
can serve a large selection of diameters with some variation in centerline locations. This will permit 
future shuttle configuration changes to be processed with minimal impacts. 

b. Define the impacts to individual platforms (usually containing multiple working levels). 

c. Design the required modifications in accordance with NASA design and review practices. 

d. Develop firm schedules based on SRB operations. Design activities should focus on the 
number of basic platforms that are available and suitable for modification. 

e. Determine the minimum number of basic platform structures that will have to be bought 
and initiate acquisition action. 

f. Arrange for staging, erection, and platform modifications at a site near the VAB. The 
platforms should be converted to their new configuration without impacting on-going operations. 

g. Complete the platform removal/installation planning and execute the work program. One 
or two platforms at a time can possibly be removed between shuttle occupancy dates in the VAB 
and new platforms installed without impact to operations. 

h. Support the Operational Readiness Inspection and turnover. Assure that all required data 
are available and that initial spares are on hand (if required). 

3.2.3.2 Avionics and Instrument Checkout Equipment - It may be possible to adapt to use with the 
LRB some of the generic equipment now being used in the VAB for checkout of SRB/STS 
electrical/electronic, and instrument sensors and systems. However, it will be necessary to procure 
and install LRB system-peculiar and specialized equipment. A safety problem could arise from 
side-by-side installation of these test sets, consoles, cables, adapters, connectors, etc. It is 
imperative that design of these devices include safeguards to prohibit improper use. Connectors 
should not be interchangeable, and a color system should be used; one for the LRB, one for the 
SRB, and one for common and multi-use checkout equipment. 

Prior to rotation and mating of the LRB, some checkout work will be done with the LRB in the 
horizontal position. Mobile or portable equipment will be required for this effort OMI's for 
operation of this equipment must include cautions and instructions for maintenance and care since 
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movement of sensitive instruments can cause them to become unreliable. Specifications for this 
type equipment must include requirements for extraordinary ruggedness. 

After rotation and mating of the LRB with the ET and Orbiter on the MLP, additional electrical and 
electronic checks will be required. Fixed equipment at the various levels in the VAB can be 
provided for this purpose. However, it must be designed to include the "murphy-proof 
requirements discussed above, and it must be located so that it will not interfere with SRB/STS 
checkout procedures when the shuttle configuration changes. Provisions must be included for 
installation of this equipment during periods when the high bay is not occupied, or in such a 
manner that it will not interfere with SRB/STS assembly and checkout. 

3.2.4 Launch Complex 39 (LC-39) Pad A & B Modifications - Changes to the configuration of the 
launch pads will be required to accommodate LRB propellant storage, transfer, and interface with 
the MLP. Provisions must be made on the pads to connect these new systems to the LPS computer 
complex in the LCC. Also, some changes must be made to the fixed service structures to 
accommodate the additional size and venting requirements of the LRB. These modifications and 
additions will require careful planning and scheduling to avoid conflict with the STS launch 
schedule. It is expected that no changes will be required to the rotating service structures (RSS), 
since one of the constraints on the LRB program is that there must be no impact on the RSS cargo 
changeout room and its interface with the orbiter. Figure 3-3 is a schedule of work required to 
modify the LC-39 pads. 

3.2.4. 1 Propellant Storage and Servicing Facilities - The LC-39 pads each have a 900,000 gallon 
liquid oxygen (LOX) storage tank, LOX vaporizer, two 1500 gallon per minute (gpm) pumps and 
almost 1500 feet of six inch vacuum jacketed (VJ) transfer line that interfaces with the MLP LOX 
plumbing. In addition there are two 10,000 gpm pumps and almost 1500 feet of 14 inch 
uninsulated transfer line, now deactivated, that were used by the SATURN V Program. The NSTS 
uses the smaller pumps and the VJ line. 

Present LOX storage will likely be adequate to supply the LRB's if future growth is modest. The 
present pumps and transfer line can support the orbiter/ET and the LRB's by extending the loading 
time. Alternatively, the existing, preserved, 10,000 gpm pumps and the uninsulated transfer line 
could support the LRB's with some LOX quality degradation and transfer inefficiencies. 

The best long range solution will probably be to keep the LOX loading time about the same as it is 
now for the orbiter/ET and maintain the same high quality LOX to the LRB rocket engines. To 
accomplish this, two 5000 gpm pumps (with motors, controllers, and accessories) and an eight 
inch foam insulated cross country transfer line will be required for the LRB's. This requires a new 
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FIGURE 3-3 



Pad-to-MLP interface. The existing six inch VJ line with a 1500 gpm pump is capable of 
replenishing the ET and the LRB's at the same time and will assure top quality LOX to both. 

An additional tower may be required on the east side of the MLP to support a gaseous oxygen 
(GOX) vent arm that will probably be needed to assure there are no ice formations adjacent to cold 
gas vents on the LRB's. The western LRB GOX vent can be reached by an arm from the fixed 
service structure (FSS). The GOX vent arms may be avoided if an arrangement and location can be 
found that will assure there is no possibility of ice forming at the vent or if ice were to form, there 
is no possibility it could strike the Orbiter's TPS. 

Propellant flow to each service mast on the MLP will be modulated by a throttling valve which will 
be controlled by the LPS. The control will be based on time and feedback from LRB liquid level 
point sensors. This digital throttling valve is a critical component in achieving accurate LOX mass 
aboard the LRB. Additional hardware interface modules (HIM) for instrumentation and electrical 
control will be required for the LOX loading system. 

Three rocket fuels are under consideration at this time for use in the LRB. They are RP-1, 
Methane, and Liquid Hydrogen, and are discussed separately below. 

LC-39 does not have an operating RP- 1 system, although there are some remnants of systems that 
were used to service the Saturn V vehicle at each Pad. Pad A has three dirt covered stainless steel 
lined RP-1 tanks that appear in good condition. Each tank has a rated capacity of 86,000 gallons. 
Both Pads have the remains of RP-1 pump houses, about 1400 feet of eight inch stainless steel 
cross country transfer line in place, and base structures for pumps and equipment. Major 
renovation will be required if RP-1 is selected as the LRB fuel. 

The Pad A tanks have a large excess capacity over the needs of the LRB's. The third tank could be 
moved to Pad B or can serve as surge storage for economical purchases, or unforeseen availabiity 
problems. Pad B will require new storage capability. Both Pads must have pumps with motors 
and controllers, storage area controls, valves, plumbing, filters, purge system, and de-waterers. 
An off loading area with manifolds for fuel transfer from deliveiy tankers will be required. 

Two 2000 gpm pumps (one pump redundant) will transfer the fuel through an eight inch line some 
1400 feet to the MLP interface connection. A new tower to allow the RP-1 line to mate with the 
MLP RP-1 system will be required. Two RP-1 valve skids are needed to support the loading of 
two LRB's, and lift-off propellant servicing masts are planned for each LRB servicing requirement 
to minimize complexity and costs. Control will be based on time and feedback from LRB liquid 
level point sensors. 
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A new LPS console and additional hardware interface modules (HIM) will be required for the RP-1 
loading system. 

The LC-39 Complex does not have and has not had any liquid methane (LCH4) facilities or 
equipment. This is a new propellant fuel to this complex and will require new construction 
equipment 

A new storage facility could be located near the existing liquid hydrogen storage facility. A 
500,000 gallon insulated storage tank should be adequate to permit some future LRB system 
growth. A vaporizer will assure proper pump inlet pressure and as LCH4 is a very light liquid, the 
fuel can be pressure transferred at slow flow rates. A location and facility for transferring the fuel 
from delivery tankers, a storage tank and vent system, and a flare stack for vapor disposal are some 
of the system elements required. A storage area control system with the necessary valves, sensors, 
filters, and plumbing are needed. To supply LCH4 to the Pad, two 5000 gpm pumps (one pump 
redundant) can be used to transfer the fuel through an eight inch VJ line some 1500 feet to the MLP 
interface connection. 

A new tower to allow the LCH4 line to mate with the MLP LCH4 system will be required if room 
cannot be found on the present LH2 interface tower. 

An additional tower will be required on the east side of the MLP to support a gaseous methane 
(GCH4) vent arm to assure that hazardous GCH4 is not released and that there are no ice 
formations adjacent to cold gas vents on the LRB's. The western LRB vent can be reached by an 
arm from the FSS. Vent lines from this tower and the FSS will be required to a new flare stack. 
Two LCH4 valve skids are needed on the MLP to support the loading of two LRB's and lift-off 
propellant servicing masts are planned for each service point to minimize complexity and costs. 
Control will be based on time and feedback from LRB liquid level point sensors. A digital 
throttling valve is a critical requirement in achieving accurate LCH4 mass aboard the LRB. 

A new LPS console and additional hardware interface modules (HIM) will be required for the 
LCH4 loading system. 

The LC-39 Pads each have an 850,000 gallon liquid hydrogen (LH2) storage tank, LH2 vaporizer, 
and almost 1500 feet of ten inch vacuum jacketed (VJ) transfer line that interfaces with the MLP 
LH2 plumbing. The Shuttle presently utilizes the facilities that were acquired and used by the 
Saturn V Program. 

The present LH2 storage is marginal for adequately supplying the additional requirements of the 
LRB's and could not support any significant growth. A 250,000 gallon storage tank with an LH2 
vaporizer can be added adjacent to the existing storage dewar. The new storage tank will be 
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connected to the ten inch transfer line at the storage area to allow the two tanks to function as a 
single supply. Cross connecting the vaporizers will increase reliability without increasing costs. 
The maximum vent rate from the LIE storage will not be increased significantly; therefore, the new 
facility vent can be tied into the present storage vent line and flare stack. Valves and controls will 
be added to allow the storage area to serve as a unified LIE supply system while giving maximum 
flexibility for maintenance and operations. 

The present ten inch VJ transfer line can support the orbiter/ET and the LRB's with no or minimal 
impact to the present NSTS LH2 loading time. The ten inch line has supported a flow rate of more 
than 1 1 ,000 gpm. 

A tower will be required off of the east side of the MLP to support a gaseous hydrogen (GH2) vent 
arm that will be needed to assure hazardous GH2 is not released and there are no ice formations 
adjacent to cold gas vents on the LRB's. The western LRB vent can be reached by an arm from the 
FSS. 

The present back pressure on the ET GH2 vent is critical; therefore, an added GH2 vent line from 
the FSS and from the new Pad east tower to a new flare stack will probably be required. 

Two LIE valve skids are needed to support the loading of two LRB's; a "tee" from the orbiter/ET 
LIE line on board the MLP will supply these two valve skids; lift-off propellant servicing masts 
(one for each propellant per LRB) are desired to minimize complexity and costs; a GH2 vent arm 
will be required to each LRB, and propellant flow to each service mast will be modulated by a 
throttling valve controlled by the LPS. The control will be based on time and feedback from LRB 
liquid level point sensors. This digital throttling valve is a critical component in achieving accurate 
LIE mass aboard the LRB. 

A new LPS console and additional hardware interface modules (HIM) will be required for the LIE 
loading system. 

Once a decision is made to select one of the three fuels, design parameters and specifications can be 
developed, and the acquisition and transition to the selected system can proceed. Traditional and 
proven NASA design review procedures will be used, and KSC-DE-512-SM will be used for 
guidance during the acquisition process. 

3.2.4.2 Fixed Service Structure Swing Arms and Vents - The Fixed Service Structures (FSS) on 
both Pads A and B are configured to support the STS with the solid rocket boosters. Neither the 
position of the Orbiter nor the ET relative to the FSS will be affected by the introduction of the 
LRB’s. The Rotating Service Structure, Orbiter Weather Protection System, and the Payload 
Ground Handling Mechanism will not be affected by phasing in the LRB's. 
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The increase in size of the boosters will impact the FSS configuration dependent upon the final 
configuration selected. Increased booster diameter will require modification to the ET gaseous 
hydrogen vent arm. The larger boosters will be able to more safely clear the FSS if the ET vent 
connection were rotated toward the north as positioned on the pad. The increased length of the 
Liquid Hydrogen and Liquid Methane boosters will require additional modifications to the ET 
gaseous oxygen vent arm. 

As discussed earlier, the Orbiter Thermal Protection System must be protected from the impact of 
ice. Therefore, methods for control or prevention of ice are mandatory. Vent arms are simple 
controls for cold gaseous boil-off from LH2 and LCH4 to prevent ice formation. Other methods of 
ice control look promising for eliminating the hazard of ice from LOX boil-off. 

The detailed design requirements for the ET vent arms modifications will be developed first They 
will be closely followed by the detailed requirements for the new vent arms for the boosters. 
Planning calls for the new booster vent arms to be mounted on the FSS (west side) and on a new 
tower to be constructed on the east side of the pad using a similar design to the FSS with proven 
components. 

The vent arms are critical for safety. All normal design, reliability, safety and logistics reviews will 
be performed. Development, acceptance, and qualification testing will take place at the Launch 
Equipment Test Facility (LETF) for the modified ET vent arm and for the new booster vent arms. 
After successfully passing the tests at the LETF, the vent arms will be installed on the towers at the 
pad. Lines will be installed to conduct hazardous vapors to the new flare stacks. The "Pathfinder" 
will permit integrated validation at the pad after completion of sub-system checks. 

Scheduling the installation of the arms at the pad should present no major conflicts as a single pad 
can come very close to supporting the maximum anticipated SRB/STS launch rate. 

3.2.4.3 Support Equipment - The pad support equipment presently dedicated to the SRB operation 
will be reviewed for potential use in servicing or checking out the LRB's. If present equipment can 
be adapted or modified for LRB use, this approach will be pursued prior to developing or acquiring 
new support equipment 

Although detailed requirements can not be identified at this time, access and service to many 
components of the LRB will be required while the vehicle is at the pad (ie; electronics, sensors, 
valves, the LRB rocket engines, and engine actuators). Support equipment will be required for 
these functions. 
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The extensible columns used to support and stiffen the MLP near the LRB support and holddown 
area will be sizable and hard to handle. A large fork-lift will have to be modified to place and 
remove these columns under the MLP (as was the Saturn V extensible column handler). 

As the depth of definition and designs proceed, support equipment will be identified and normal 
acquisition steps will be followed. 

3.2.5 Launch Control Center (LCC) Modifications - The Launch Control Center will require 
additional hardware and software for monitoring and controlling the LRB's. The existing SRB 
hardware and software will have to be retained in the LCS until SRB's are no longer utilized by the 
NSTS. Modifications to the facility should be minimal, primarily those needed to install extra 
consoles and racks to accommodate added software and dual flow management. 

3.2.5. 1 Launch Processing System (LPS) - The planned up-grade of the launch processing 
system should include the capability to handle the requirements of both SRB's and LRB's in flow. 
During the early stages of the LRB design program, LPS requirements will be developed by GDSS 
and provided to MSFC. With NASA coordinating both programs, an orderly transition of LRB 
requirements into the up-graded LPS will have minimum cost impact The integration of LRB's 
into the existing LPS system will require a detailed study of the existing system. 

3.2.5.2 Software Development - Additional software will be required for control and monitoring 
of the new and modified ground support systems and equipment. New software will also be 
required to monitor and control the LRB prelaunch processing on the pad. GDSS will provide the 
requirements and parameters for developing the LPS software for the LRB's. 

3.2.5.3 Dual Flow Management - The introduction of LRB's will take place while SRB's are in 
flow. This will require that the launch control center have the capability to dedicate both console 
and software processing to SRB's and LRB's. During the early stages of design, GDSS will 
identify the LRB requirements for monitoring and control. Through a GDSS/MSFC/KSC team 
effort, dual flow management problems will be resolved, and appropriate OMI's will be prepared. 

3.3 Ground Support Equipment (GSE) Acquisition - KSC has a history of competendy designing 
and acquiring ground support equipment for its space programs. Examples of past acquisitions are 
the Multi-Mission Support Equipment (MMSE) transporter, cargo canister, strongback, payload 
environmental transport system (PETS), ET transporter, Shuttle/MLP crawler-transporter, and 
numerous others (ie; cranes, slings, dollies, vehicles of all types, and SRB retrieval systems). 
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From this experience base, any new GSE needed for the LRB program can be designed and 
procured. NASA and DOD procurement regulations and FAR’s will be followed in the 
procurement process. KSC-DE-512-SM and KHB 1200.1 A will be used as guidance for the 
design, acceptance, test, verification, and validation during the transition program. 

3.3. 1 LRB Transporter - If it is determined that a new ground transporter is needed for the LRB at 
its manufacturing site, the design should take into account the LRB handling and movement 
requirements at the launch site, thus allowing NASA to realize savings by multiple procurement. In 
the event that the ET transporter can be modified to move the LRB and maintain the capability to 
move the ET, this alternative will be pursued during this transition program. 

3.3.2 Lifting and Rotation Devices - It will be necessary to design and acquire slings, a 
strongback, or attachment brackets to handle the LRB during loading onto and unloading from the 
barge, during rotation and movement in the VAB, and during mating with the ET and orbiter on the 
MLP. If this same type equipment is designed and used at the manufacturing site, duplicate items 
will be procured for use at the launch site. If KSC-unique items are needed, they will be designed 
at KSC and acquired using KSC procedures. 

3.3.3 Special Test Equipment and Tools - At some point in time during the LRB DDT&E program 
and transition at the KSC launch site, a requirement will develop for special tools and test 
equipment although it is too early in the program to do it now. When such items are identified, 
KSC or MFSC, as appropriate, will initiate the necessary acquisition process to assure that support 
is in place when required. 

3.4 Operations Support and Logistics - Logistics Planning and Engineering, Product Support 
requirements, and Operations Support necessary for the LRB development program are essential to 
an orderly transition. Government, contractor, and sub-contractor personnel who are involved in 
the LRB program management, planning, concept and/or specification development, design, 
manufacture, assembly, checkout, verification, launch operations, maintenance and supply 
support, training, facilities, transportation, and ground support equipment (GSE) are also indirectly 
or directly involved in logistics and operations. The logistics program will be driven to some 
degree by the design, manufacture, transportation, storage, assembly, checkout, and operations 
concepts which evolve from program management decisions, and by directed program milestones. 
Figure 3-4 depicts the relationship of logistics and support requirements to major LRB program 
milestones. 
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LRB LOGISTICS SUPPORT SCHEDULE (PRELIMINARY) 
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FIGURE 3-4 







3.4.1 KSC Manpower Impact - It will be necessary to increase the contractor work force at KSC 
to prepare LRB processing and launch facilities and to accommodate the requirements of the 
transition and flight test programs. Additional NASA contract administration and surveillance 
personnel may be required at KSC in addition to any MFSC personnel who may be temporarily 
located at KSC during transition. With the addition of manpower, the requirement exists for the 
added office space, housing, transportation, and other routine support that accompany increases in 
personnel strength. Planning for these accommodations must take place at a very early date since 
personnel increases must usually be in place before other work begins. 

3.4. 1.1 Training and Certification of Personnel - One of the principal impacts on personnel will be 
the extensive training and certification required to assure a quality work force ready to process and 
launch the new LRB space vehicle. This task is an important part of the Integrated Logistics 
Support Program, and it is implemented by NASA and NASA contractors as part of all new 
systems acquisitions. Training will consist of both formal and informal courses, on the job training 
(OJT) and testing for compliance and certification. 

3.4.1.2 Dual Flow Manloading - One of the NASA goals is to transition the LRB system while 
maintaining the planned shuttle launch program. To accomplish this objective will require that a 
dual processing flow be established, and that added manpower be integrated to support it Some 
people will be required to work on both the SRB and the LRB programs once the vehicles are 
rotated for stacking in the VAB. This may require that special OMTs be devised and that additional 
supervisors and quality control people are in place to maintain the required safety and quality 
standards. During the prelaunch and liftoff activities on the launch pad, exceptional care must be 
taken to assure that use of OMTs and LPS software are properly supervised. 
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3.4.2 Documentation Development and Verification - LRB program documentation will be 
developed and maintained in accordance with the requirements of JSC 07700 Directives and other 
pertinent NASA issuances. Technical documentation pertaining to KSC facilities and equipment 
shall be provided as specified in the NASA LRB acquisition contracts, and shall be written, 
verified, and published in accordance with DOD-D-IOOO, KSC-DE-512-SM, KHB 1200.1 A, and 
KMI 8610.11. Vendor data, such as maintenance manuals will be used to the maximum extent 
possible. Special requirements and specifications having an impact on maintainability shall be 
documented and furnished to the O&M agency having responsibility for development of OMI's. 

3.4.3 The Integrated Logistics Support System - Decisions made during the development program 
will have a lasting effect on the configuration of the LRB and on its operations and support 
infrastructure which will impact cost, availability, and utilization for the life cycle of the program. 
The part of total program costs that often has reduced visibility during hardware development can 
be identified with the operational and logistics support costs which accumulate over the life of the 
hardware and during the employment of the system. Effective program management control of life 
cycle costs begins with the concept, planning, and design phases of a DDT&E program. Active 
interface between logistics support personnel and the planners, designers, engineers, and 
manufacturers is necessary during system design to assure economical production, supportability, 
maintainability, and availability of the operational system. This philosophy will be followed 
during the DDT&E and operational life of the LRB system. It is the genesis of an integrated 
logistics support program. 

One cost control concept to be used on this program is to make use of existing facilities, whenever 
and wherever possible, if they can reasonably be adapted or modified to fit requirements. 
Integration with the Shuttle Processing Contractor operations and support systems early in the 
DDT&E program should result in a shorter learning curve and further cost savings. 
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3.4.3. 1 Logistics Engineering and Logistics Support Analyses (LSA) - The processes by which 
the essential interface between logistics personnel and designers can be coordinated are included in 
the LSA. Maintenance Engineering Analyses (MEA's) of preliminary designs, and participation in 
all design reviews by logistics personnel will help assure the acquisition of hardware that is 
economically supportable. Early consultation between design engineers and logistics support 
personnel will also assist in timely procurement of long lead-time of hardware. 

Considering the complexity of the LRB program, it is essential that an Integrated Logistics Support 
Plan (ILSP) be developed. Such a plan will facilitate the coordination of engineering, design, and 
support functions during the LRB development program and during transition and turnover to the 
operational program. The elements of the system will be categorized into a work breakdown 
structure (WBS) for use by all design, production, operations, and support functions to assure the 
proper allocation of resources and to assist in implementation of the ILSP. MIL-STD-881 provides 
guidance for development of WBS. The ILSP is a dynamic document which begins with broad 
objective-oriented concepts and becomes more specific as a task and milestone oriented document 
as the transition program develops. It must be frequently up-dated in response to new management 
directives and activity feedback to be useful as a "working document" and to assist in orderly 
transition. The ILSP will become a working document as soon as hardware configuration becomes 
viable (usually at the preliminary design review) and will address the following subjects and be 
formatted approximately as follows: 

a. System Description 

b. Program Management 

c. Applicable Documents 

^d. Operations Concept (Including Processing Row) 

e. Maintenance Concept 

f. Acquisition Strategy and Procurement Approach 

g. Test and Evaluation Concept 
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h. New Technology Impact 

i. STS Interface Impact 

j. Operational Logistics Support Concept 

k. Milestone Schedule Charts for each Program Element and LS A Task 

l. Manpower and Personnel Requirements 

m. Configuration Management System 

n. Logistics Management Information System 

o. Logistics Management Responsibility Transfer (LMRT) Concept 

p. Sustaining Engineering Concept 

q. Integrated Supply Support Plan (ISSP) 

r. Logistics Support Analysis (LSA) using MIL-STD-1388-1 and 1388-2 guidance to include 
interfaces with the following tasks, as applicable: 

1. System/Equipment Design Program 

2. Reliability Program 

3. Maintainability Program 

4. Human Engineering Program 

5. Standardization Program 

6. Parts Control Program 

7. System Safety Program 

8. Packaging, Handling, Storage, and Transportability Program 

9. Initial Provisioning Program 

10. System/Equipment Testability Program 

11. Survivability Program 

12. Technical Publications and Documentation Program 

13. Personnel Training and Certification, and Training Programs 

14. Facilities Program 
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Logistics planning and support guidance is provided in a wide range of policy directives and 
management instructions. Some which apply are listed below: 

NHB 4100.1 - NASA Materials Inventory Management Manual 

NHB 6000. IB - Requirements for Packaging, Handling, and Transportation for 

Aeronautical and Space System, Equipment and Associated Components. 

MSFC HDBK-527A - Material Selection Guide. 

JSC 07700, Volume XII - Space Shuttle Program Integrated Logistics Requirements 
Qatest Revision, including referenced applicable documents.) 

JSC 08151 - Space Shutde Program Maintenance Baseline Requirements. 

JSC-SE-S-0073 - Space Shuttle Fluids, Procurement and use Control. 

DOD-D-1000 - Drawing, Engineering and Associated Lists, Specification for 
DOD4100.38-M - Provisioning and Preprocurement Screening Handbook. 

AF Regulation 800-8 Acquisition Management-Integrated Logistics Support (ILS) 
Program. 

MIL-D-9024 - Packaging, Handling, and Transportability in System Acquisition Items. 
MIL-HDBK-217 - Reliability Prediction of Electronic Equipment 
MIL-HDBK-472 - Maintainability Prediction. 

MIL-STD-470A - Maintainability Program for Systems and Equipment. 

MIL-STD-480 - Configuration Control - Engineering Changes, Deviations and Waivers. 
MIL-STD-721 - Definitions of Effectiveness Terms for Reliability, Maintainability, Human 
Factors, and Safety. 

MIL-STD-794 - Packaging 

MIL- STD-881 - Work Breakdown Structure for Defense Material Items. 
MIL-STD-975-NASA Standard Electrical, Electronic, and Electromechanical (EEE) parts 
list. 
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MIL-STD-1366 - Packaging, Handling, Storage, and Transportation Systems Dimensional 
Constraints, Definition of. 

MIL-STD-1367 - Packaging, Handling, Storage, and Transportation 
Program Requirements. 

MIL-STD-1369(EC) - Integrated Logistic Support Program Requirements. 

MIL- STD- 1375 - Provisioning, Initial Support, General Requirements for. 

MIL-STD-1379 - Contract Training Programs. 

MIL-STD- 1388-1 - Logistic Support Analysis. 

MIL-STD-1388-2 - Logistic Support Analysis Data Element Definitions. 

MIL-STD- 1552 - Provisioning Technical Documentation, Uniform DOD Requirements for. 
MIL-STD- 1561 - Provisioning Procedures, Uniform DOD Requirements for. 

KHB 1200.1 A - Management of Facilities, Systems, and Equipment Handbook. 

KHB 3410.1 - Implementing Instructions for KSC Systems, Safety and Skills Training and 
for Certification of Personnel. 

KHB 4000.1 - Kennedy Space Center Supply Manual. 

KHB 5310.1 - Government - Industry Data Exchange Program and Alert System. 

KHB 5310.1 1 - Nonconformance/Problem Reporting and Corrective Action System 
KMI 8610.1 1 - Distribution of Operations and Maintenance Instructions 
K-SMO- 12.01 - Kennedy Space Center Operational Logistics Plan. 

K-STSM- 12.5.04 - Ground Operations Training Plan for STS Operations. 

KSC-DE-512-SM - Guide for Design Engineering of Ground Support 
Equipment and Facilities for use at Kennedy Space Center (Including referenced documents). 
Some of the more important elements of logistics support which must be considered early in the 
DDT&E program are discussed in the following subparagraphs. 
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3.4.3.2 Logistics Management Information System (LMIS) - The LMIS includes all information 
generated for or used by logistics managers in managing existing LRB program resources or in 
acquiring or supporting others. It can be used by both NASA and contractor managers. Its 
baseline is the LRB program ILSP and transition ILSP as modified to keep up with progress and 
program changes. The WBS, which encompasses the entire LRB program plus pertinent 
management directives and schedules will be the framework upon which it is structured. 

The basic required elements of the Logistics Management Information System (LMIS) are data on 
cost, schedule, and performance applied to the various functional tasks as broken down in the 
LSA. Management must have information upon which to base decisions on design changes, 
tracking of program milestones, budgetary inputs, other program interfaces, trade study results, 
and various program support problems. 

An efficient Configuration Management System is essential to a useful LMIS. Program 
Management must tie the two together to save both time and resources. Existing in-house 
contractor information systems plus those at KSC should provide necessary data to support 
management reviews, a performance measurement system, procurement, inventory control, 
maintenance, safety requirements, and schedule tracking. They can be augmented by a 
PERT/TIME type system if management determines that one is needed. At KSC, the selected 
contractors should make maximum use of the KSC systems and procedures. The KSC Inventory 
Management System (KIMS), Maintenance Management and Control System (MMACS), the KSC 
Data Management System (KDMS), the Problem Reporting and Corrective Action System 
(PRACA), and the Government-Industry Data Exchange Program (GIDEP) Alert System will be 
used for management support A "Red Flag" system will be established to highlight urgent 
problems. 

Manpower needed to operate existing systems in support of management requirements for 
information, and to prepare for and support review activities, should be programmed. 
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Data requirements schedules will be established to support program milestones. These 
requirements will appear very early in the program and will continue through DDT&E and into the 
operational lifetime of the system. See Figure 3-4. 

3.4.3.3 Maintailability Analysis - This analysis is a compendium of individual maintainability 
engineering analyses (MEA) of every element, component, or part of the LRB and its launch 
support systems. It will be performed early in and concurrent with the design process, and is 
dependent on inputs from both designers and logistics/maintenance personnel. When properly 
performed, it will help determine the detailed design approach, and will influence system costs, 
schedules, facilities, and performance. It is led by the system maintenance concept, but also serves 
as feedback data to influence changes in that concept It precedes final design acceptance. 
Following are some of the factors to be considered in performing the maintainability analysis: 

a. System reliability criteria (FMEA’s, Mission and Operations profile, critical items lists) 

b. Modeling requirements (for quantitative estimates and allocations of time to repair, design 
specification impact cost of acquisition, and life cycle cost) 

c. The allocation process as it relates to specific subsystem or component preventive and 
corrective maintenance requirements. This top down process is a technique of budgeting 
maintenance tasks among various items of a system to meet established maintenance goals. It will 
be iteratively updated to reflect refinements and changes during design evolution, and to insure 
consistency with the design specifications. 

d. Predictions of the ability of the system, subsystem, or equipment to achieve 
maintainability requirements for each level of maintenance specified. Values are based on criteria 
such as mean time between failure (MTBF), mean time to repair (MTTR), fault isolation, false 
alarm rates, tests (using built-in or external test equipment), times to disassemble, interchange, 
reassemble, align and checkout Also considered will be system physical and functional data, parts 
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and labor costs, design tradeoffs, and time measurement methodology. The predictions are 
normally accomplished using a hierarchial structure of predetermined standards based on the time 
measurement system (MTM) references in NHB 5300.4 (IE) Appendix E. and guidance for 
predicting maintainability times in MIL-HDBK-472. They are to be used in maintenance planning 
and provisioning of spares. 

e. The testability of systems, subsystems, or parts based on design criteria and 
characteristics identified to effectively detect, locate, and isolate faults to a specified level of 
maintenance. The latest available built-in test equipment (BITE) and checkout and alignment 
systems should be included to minimize maintenance and checkout costs. 

f. Verification of maintainability of the subsystem design in accordance with established 
criteria. This is accomplished by analysis, assessment, test, demonstration, or combinations 
thereof. 

g. Availability of maintenance capability (ie; shops, tools, personnel skills, contractor 
support) and supply support. Existing KSC facilities, resources, and procedures will be used to 
the maximum extent possible. 

Maintainability analyses will be the responsibility of the design organization with active 
participation by maintenance and logistics personnel before and during all design reviews. These 
maintainability requirements data will be developed as early as feasible in the design evolution so 
that maximum benefit to design drawings and specifications can be realized. Appropriate 
Standards, Specifications, Handbooks, and Directives from both Government and Industry will be 
consulted by designers and logistics personnel for detailed guidance during the design cycle. Many 
are listed in Section II of KSC-DE-512-SM. In addition. Sections VII and VIII of 
KSC-DE-512-SM provide expanded guidance for actions essential to the design tasks and initial 
provisioning of spares, ground support equipment and facilities. Much of the information in this 
publication is also relevant to the design of the flight article hardware of the LRB system. As soon 
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as long lead time parts are firmly identified, logistics engineering personnel will initiate 
procurement action in support of the fabrication process. 

Appropriate allocation of manpower from the design and logistics organizations will be made 
within the scope of contracts and program management guidelines, as soon as needed to 
accomplish the design and logistics tasks, including the maintainability analysis. When 
maintainability analysis reveals the need for procurement of parts or acquisition of tools, GSE, or 
facilities the logistics personnel will help develop budgeting and programming actions as necessary 
within management guidelines. 

Schedules for logistics and maintainability analysis actions will be developed as necessary to 
conform to master program management schedules. Figure 3-4 shows the relationship of the 
Maintainability Analysis (MA) to master program milestones. 

3.4.3.4 Provisioning and Procurement - Provisioning activities during the DDT&E and transition 
programs will be limited to the acquisition of hardware and spare parts needed for prototype and 
design proofing, and program test activities. The scope of the test program will influence the 
magnitude of provisioning and procurement of spares during transition and prior to logistics 
management responsibility turnover (LMRT). As systems designs reach baseline configuration the 
prime contractor will develop provisioning technical documentation for delivery to NASA, will 
assist NASA in long lead time item identification, initial operational spares requirements and the 
development of life cycle cost estimates for program budgetary cycles. 

Initial and follow-on spares provisioning criteria and technical documentation are based on products 
of the LSA. Requirements include hardware identification/costing, indentured parts lists, fuel and 
fluids requirements quantification, support and test equipment identification, and types/quantities of 
pressurants needed. Lists will be compatible with the planned levels of maintenance, and 
distribution of assets after their acquisition. Common hardware (ie; commercial off-the-shelf or 
available from government sources) will be identified as direct procurement candidates. Detailed 
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provisioning data elements are described in JSC-07700, Volume XU, Table 5.1, and will be used 
as guidance in conjunction with formats recommended by MIL-STD-1388-1 and 2. 

A supply support concept will be developed based on contract stipulations, resource limitations, 
maintenance concepts, and DDT&E program objectives and management direction. LSA data 
sheets will be reviewed at provisioning conferences by supply, maintenance, and engineering 
design personnel to determine quantities of spares needed to support the DDT&E program. After 
design baseline, additional provisioning conferences will be conducted to develop 
recommendations for initial operational spares stockage. When design changes occur after spares 
have been purchased, inventory control and stock rotation procedures will be established to assure 
modification or retrofit of all spares which can be economically upgraded. In addition to 
developing provisioning technical documentation, the prime contractor will develop O&M 
documentation to support repair of reparable items and to facilitate the retrofit of spares in stock. 
Design change impact to O&M documentation will be an iterative process so that when the LRB 
system and its facility support infrastructure reaches operational status and LMRT, current usable 
O&M documents will be available for delivery to NASA. Once a baseline configuration is reached 
design drawings and O&M documentation will be placed under configuration control. Active 
coordination with and participation by the KSC SPC and BOC will be implemented to assure 
complete compatibility with the SPC O&M procedures and activities during transition. 

Manpower and money are the elements needed to accomplish the provisioning tasks. Procurement 
of provisioned items will be as provided for in program management directives, budgets, and 
contracts. 

Schedules will conform to program milestones as shown on Figure 3-4. 

3.4.3.5 Transportation and Handling - The manufacturing concept and location, the storage and 
holding sites, and the processing and checkout flow will determine the magnitude of the 
transportation and handling tasks for the LRB and its support systems. Pending development of 
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these concepts and relevant management decisions, the scope of this requirement will be limited to 
the movement of the LRB from the barge site to launch processing site, such handling as is 
necessary for movement and processing of LRB elements, and the miscellaneous transport needs 
which will be provided at KSC through the STS Transportation Control Center using NASA or 
GSA resources. 

The existing excellent transportation system at KSC will be used for generalized support, and the 
KSC Transportation Coordination Center will serve as a focal point to fulfill requirements and 
maintain status of all material movements to and from KSC. The GSA Interagency Motor Pool at 
KSC will be used to the maximum degree possible. Movement and lifting of the LRB and major 
support equipment will be accomplished to the maximum degree possible by using the STS external 
tank transportation and logistic support system, or a similar concept. Use of the Navy Trident 
Basin crane will be considered for barge unloading. 

An Integrated Transportation Plan (ITP) will be developed to tie together the concepts, 
requirements, and resources to assure the efficient transportation and handling support to the LRB 
DDT&E program, launch site transition, and the follow-on operational program. 

In order to satisfy the LRB transportation and handling requirements, program management 
decisions must be made early to establish the manufacture, storage, and transportation concepts. 
The facility and equipment support needed must be identified and NASA must plan for the 
acquisition of any items which cannot be obtained from within existing KSC or MSFC resources. 
Manpower, equipment, and dollar resource requirements will depend on the scope and content of 
the ITP. Figure 3-4 illustrates the relationship of these requirements to program progress. 

3.4.3.6 Training - Initial and refresher training and certification will be limited to personnel whose 
duties do not directly involve flight operations. Contractor or subcontractor personnel who have 
preflight processing, logistics, or maintenance jobs will receive training as determined by the 
established operations, maintenance, and supply concepts, and as directed by NASA. 
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New designs or acquisition of new hardware, or modifications to existing systems and equipment 
dictate that people involved in the maintenance and support of such new items or systems receive 
training and be certified as competent prior to working with them. These training requirements arc 
identified as a result of the maintainability analysis and the LSA. Design engineering personnel will 
assist in defining the training requirements for new hardware systems which they design, and 
providing operations and maintenance requirements specifications (OMRSD's) to support O&M 
documentation and personnel training. 

As new requirements are identified, logistics support organizations will establish new training 
programs and schedule personnel to receive training in the new skills required and to be certified as 
competent. In-house training procedures for contractor offsite training, and for safety and skills 
training at KSC will take guidance from K-STSM-12.5.04, "Ground Operations Training Plan for 
STS Operations" and from KHB 3410.1, "Implementing Instructions for KSC Systems Safety and 
Skills Training and for Certification of Personnel". 

Training resources available at KSC will be used to the maximum extent possible for training of 
people located at the launch site. 

Training schedules will be developed to support new hardware acquisition schedules and other 
LRB program milestones. Figure 3-4 shows the approximate time when training becomes a major 
factor in program support. 

4.0 VERIFICATION AND VALIDATION 

Acquisition of new facilities and equipment and modifications to the VAB high bays, the 
MLP's and the launch pads will require verification and validation by inspections, tests, and 
demonstrations. A schedule will be developed for the KSC modifications to identify those 
verifications and validations that can be performed with minimum impact on the scheduled SRB 
flights. Typically, the critical events are cold flow tests, pathfinder tests, tanking tests, operational 
readiness inspection, and flight readiness firing. 
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4. 1 Cold Flow Tests - The propellant system modifications at the launch pad include new/modified 
fuel storage and transfer systems. This test will ensure design specifications have been met, the 
integrity of the systems is verified and the system meets the operability requirements. The cold 
flow test will utilize the launch processing system demonstrating its ability to control and monitor 
the flow of the propellants. These tests will be similar to cold flow tests used on other rockets that 
KSC personnel are familiar with. 

4.2 Pathfinder Tests - Two test-LRB's will be utilized as pathfinders to check mating clearances, 
and mechanical, electrical, and fluid hookups. The test in the VAB will check handling of the 
LRB's, mating with the ET and orbiter on the MLP, clearances of the work platforms, and other 
fit, form and function requirements. 

The pathfinder test at the launch pad will check mating and clearances with the RSS, FSS, 
proposed additional towers, swing arms, electrical systems, mechanical systems, fluid systems and 
the launch processing system. The pathfinder tests are similar to pathfinder tests conducted by 
KSC for the NSTS. 

4.3 Tanking Tests - The external tank and the LRB's will be filled under the same conditions as an 
actual launch. This will demonstrate the operational readiness of the propellant fuel systems, the 
launch processing system and the operations personnel. 

4.4 Operational Readiness Inspection - This inspection is similar to NSTS inspections conducted 
by KSC. The LRB's will not introduce any major change to this inspection process. GDSS will 
provide inputs to the cuiTent operational readiness inspection documents and be available to assist 
in the actual inspection. System documentation will be provided in a form that shows the entire 
system with all components clearly identified to aid in this inspection. 
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4.5 Flight Readiness Firing - This operational test will demonstrate that the NSTS with LRB 
boosters is ready for flight. GDSS will work with the KSC SPC to prepare a procedure with 
recommended sensing devices and parameters to be monitored during this test The results of the 
tests will be reviewed by GDSS for any discrepancies from design parameters, and the results of 
the analyses will be provided to MSFC. 
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APPENDIX 4 


AUTOMATED MANAGEMENT AND 
OPERATIONS 
PLAN 



SECTION 1 
INTRODUCTION 


Recent advances in automated technologies have necessitated investigation their 
augmenting, and in some cases replacing, current systems. Incorporation of many of these 
technologies into existing programs for reasons of cost, quality, or reliability suggests that 
these technologies may be applicable to the LRB. The following plan will examine several 
new and available technologies that could become a part of the overall LRB program. 

1.1 OBJECTIVE AND APPROACH 

The objective of this plan is to determine what forms of automation and robotics are 
available and applicable to the LRB program. The approach will be to select areas within 
the program that seem to have potential for the use of advanced automation and robotic 
technology and to apply some selection criteria to determine if the use of these technologies 
would be beneficial. The plan will also identify possible strategies for implementation of 
these technologies in the selected areas. 

1.2 AREAS OF APPLICATION 

Figure 1.2-1 depicts the three general areas of the LRB program as DDT&E, Production, 
and Operations. Within these three areas, several opportunities for advanced automation 
and robotics have been selected based on industry as well as other programs within NASA. 
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Figure 1.2-1. Areas of Application and Their Relationship to Program Phases 






These target areas for new technology incorporation are manufacturing, management and 
administration, logistics support, design, ground operations, and flight operations. Table 
1.2-1 shows suitable applications for automation found within each target area. 


Table 1.2-1. Automation Candidates For Target Areas. 


DESIGN 

• DFM/DFA Analyses 

• CAD/CAM 

• CAE 

• Scheduling 


MANUFACTURING 

• Configuration Management 

• Methods and Standards 

• Scheduling, Planning & 

Procurement 

• Tooling 

• Assembly and Fabrication 

• Overhall/Rebuild 

• Quality Control 

• Budgets 


GROUND OPERATIONS 

• Work Stations 

• Work Instructions 

• Spares/Parts Provisioning 

• Fault Detection and Isolation 

• Robotics 

• Real-Time Status Reporting 

• Scheduling 

• Launch Operations 


LOGISTICS SUPPORT 

• Inventory Control 

• Procurement 

• Retrieval 

• Shipping and Receiving 

• Consumeables/Expendables 


FLIGHT OPERATIONS 

• Scheduling & Planning 

• MCC Reconfiguration 

• Flight Monitoring 

• Problem Assessment 

• Data Load Preparation 

• Feasiblity Analysis and 

Payload Manifesting 

• In-Flight Fault Detection 

and Isolation 

• Payload/Vehicle/ 

T racking/Status 


MANAGEMENT AND ADMINISTRATION 

• Centralized Program Control 
■ Problem Assessment 

• Launch and Flight Operations 

• Monitoring 

• Real-Time Status for Decision 

Making 

• Scheduling and Planning 

• DBMS for Analysis and Study 

• Security 

• Cost Control 

• Configuration Control 

• Documentation Production 

• Information Dissemination 

• Manpower Utilization 



This scenario adheres to the basic CEM (Computer Integrated Manufacturing) philosophy of 
providing information systems to support the integration of applicable areas within the 
program so that the program operates as a single integrated system instead of autonomous 
groups, production areas, or units. A survey by the National Research Council discovered 
the following gains when elements of CIM were implemented: 

• Engineering design costs were reduced by a factor of 2 

• Productivity increased from 40% to 70% 

• Lead time was reduced from 30% to 60% 

• Product yields were from 2 to 5 times higher 

• Personnel costs fell by 5% to 20% 

1.3 MASTER DATA BASE CONFIGURATION 

To achieve this integrated system of design, production, and operations, a powerful master 
data base which is accessed by a highly automated and intelligent front-end user interface is 
needed. With the master data base and front-end expert system in place, the goal of 
achieving an integrated program is feasible. The master data base would be used 
throughout the program life and would not only serve the different elements of the 
program, but would also be the "corporate" memory of the program to track the design 
decisions, program changes, and cost changes, as well as production outputs. 

The master data base as shown in Figure 1.3-1 could be either a distributed data base with 
various pieces of the data base strung along the "back bone" of some network or could be a 
single data base that is a node on some network. The complexity and scheduling for 
development of the LRB will dictate the hardware requirements for the given configuration, 
but at this point the most cost effective approach seems to be a configuration with a small 
to medium sized local mainframe housing the front-end expert system and functioning as a 
front-end to the master data base which would be a virtual entity made up of information 
stored on computers in various locations. There are powerful computer resources such as 
large mainframe computer networks and applicable Manufacturing Resource Planning 
(MRP II) software within General Dynamics which could be made available for the LRB 
program. Access to computers within NASA with applicable information could also be a 
possible source of data base information. 

The master data base would be a central element to the automation of the LRB program. As 
shown in Figure 1.3-1, the master data base would be the focal point for the collection of 
all the data that pertains to the program. This includes data from such diverse areas as 



program management to operational procedures. All data and decision tools would be part 
of this master data base. 



OPERATIONS CONSOLE 


Figure 1.3-1. Master Data Base Configuration 


In conjunction with the master data base the intelligent user interface would allow for 
manipulation of the stored information. This expert system would allow for the 
recombination, extraction, and interpretation of data within the master data base by those 
given access. These individuals or groups of individuals could be from General Dynamics 
and its subcontractors, NASA, or others with the "need to know" such information. 
Access could be controlled through passwords. 


1.3.1 PFS I GN KNOWLEDG E CAPTURE 


Design Knowledge Capture is a preliminary and important function in the development of 
a truly automated program. As a portion of the front-end expert system, the design 
knowledge capture portion contains items such as requirements, design specifications, 










design rationale, cost projections, scheduling, materials listings, organizational structuring, 
responsibility assignments, etc. 

Since the DKC system is at the heart of the automation process of the program, it is 
important to understand the functions of the DKC system. There are three major functions 
of the DKC: 

1. Design Knowledge Acquisition 

The DKC system collects all information about the program as a whole. 

This includes the following: 

a. Design Rationale 

b. Design Drawings 

c . Specification Requirements (government and other) 

d. Schedules 

e. Costs 

f . Operational Considerations 

g . S afety Requirements 

h. Materials Lists 

i. Testing Requirements 

2. Design Knowledge Manipulation 

Given the above as well as other inputs, the DKC system develops several 

outputs. These include the basic multi-dimensional data base matrices. 

3. Knowledge Synthesis 

Knowledge Synthesis is a process where the DKC system is capable of 
developing information about the design, production, or operations of the 
LRB's from the information stored in the data base. Information could 
include, but is not limited to, the following: 

a. Operational Procedures 

b . Operational Parameters listing for Real Time operations usage. 

c . Code Generation for Fault Diagnostics 

While the incorporation of a knowledge synthesis ability into the 
front-end expert system is attractive, especially in the area of flight 
operations, its technological feasibility is a prime factor. This feasibility 
will be discussed in Section 5. 



Designated experts in each phase of the program would help develop the DKC system by 
providing as much up-front essential information as possible. The DKC system/data base 
and expert system designers would provide standard forms for all "experts”. These forms 
would ask each what information was needed from the data base to accomplish a certain 
task and what outputs would result from this task. 

1.3.2 DATA BASE STRUCTURE 

The structure of the master data base is based on an object-entity relationship approach. 
This involves the use of a frame based system for identifying and manipulating the data 
within the data base to allow for an almost infinite arrangement of data relationships and to 
allow the data to be manipulated by intelligent inference engines within the expert system. 
Figure 1.3-2 describes and example object/frame. The object-entity relationships as 
•established by the front-end expert system designers would allow data base queries in a 
"free form" type interface, a standard user interface, and a schematic information interface 
allowing queries on object or system relationships within the LRB corresponding to a 
functional flow diagram. 



SLOTS/VALUES/ATTRIBUTES 


Figure 1.3-2. Frame Object 



Figure 1.3-3 shows the frame structure. All information about object 1 in the data base is 
inherited by all following objects unless otherwise desired. This may be achieved without 
coding, records, fields, or files. Objects would be "children" of Part X (as referred to in 
Figure 1.3-2) and inheritance would provide operational flow for procedures and 
diagnostics in the specific area of the LRB system. Each object could occur only once but 
have infinite relationships with other objects, and information about each object could be 
connected to other objects. 



Figure 1.3-3. Frame Structure 
1.4 SELECTION CRITERIA 

The selection criteria for determining whether or riot to implement a given automation 
strategy are as follows: 


• Technological Risk 

• Integration with STS 

• Cost 

• Quality/Safety 

To determine the technological risk, the availability and integrity of the proposed strategy 
will have to be assessed given current information. The criterion of STS integration would 



mainly have an impact on the strategies under consideration for operations (both ground 
and flight) applications. Given existing knowledge, it must be determined that a given 
automation strategy can be phased into the current system without undue stress on present 
operations. The cost and potential payback of a strategy should also be considered when 
examining automation strategies. An automation strategy should not only be implemented 
because the technology exists, but should also offer cost benefits. Although cost is 
probably the most significant factor when considering different forms of automation, the 
quality and safety inherent in automated systems should also be influential in evaluating 
them. Automated systems can increase the quality of products and communications while 
eliminating many time consuming processes, and can also be used in areas where human 
safety is a factor. 



SECTION 2 
DESIGN 


The design of a product must be simplified for automation and assembly in order to 
automate production of most parts. Simplification of product design is beneficial from a 
cost standpoint even if robots or hard automation prove to be too expensive for use in an 
area of production. Design for Manufacture (DFM) means the avoidance of features in a 
product component that are unnecessarily expensive to produce. To successfully adhere to 
DFM, Design for Assembly (DFA) must be practiced. DFA techniques primarily aim to 
simplify the product structure so that assembly costs are reduced. This simplification of 
design results not only in part and assembly cost reductions, but also in improved reliability 
and reduction in inventory and production-control costs. While it estimated that 
DFM/DFA and CAD(Computer Aided Design)/ (Computer Aided Manufacturing) CAM 
operations make up 10% of total recurring cost, DFM/DFA also affects direct support labor 
and hands-on labor, another 17% of the total recurring cost. DFA recognizes that assembly 
problems should be considered at early stages of product/part design. 

Although there is much interest in having DFM and DFA techniques available on 
CAD/CAM systems, it is too late to make radical changes to a product once a design has 
been sufficiently detailed to enter it into the CAD/CAM system. To perform the early 
design analyses needed, computer software is available that evaluates the efficiency and 
assembly costs of a given assembly sequence. Since this analyses, which can occur even 
at the sketch stage, is of such potential benefit in the cost and technological areas, the 
implementation of this relatively inexpensive software could be of great benefit. The early 
information on the design of the product could also provide needed information to develop 
an efficient factory layout. With its data base design, this software would be compatible as 
a part of the master data base and would justify its cost with savings in areas such as 
materials, manufacturing, and tooling. The software could be easily accessed through the 
front-end expert system and would run on a computer being used for design purposes. 
This computer could be the local mainframe or one at a remote site. 


DFM/DFA analyses is an important design activity where automated tools are applicable, 
but it is only a starting point in automating design. Product design includes CAD/CAM 
design, requirements analyses, documentation activities, scheduling, and information 
control. Sections 2.1 through 2.4 discuss automation strategies for these design activities. 

2.1 CAD/CAM 

The trend towards automated manufacturing processes makes simultaneous engineering 
between designers, process and manufacturing engineers, purchasing agents, marketers, 
accountants, and management vital. A three dimensional CAD/CAM system is yet another 
aspect of an overall CIM strategy. These systems would provide a wide variety of 
information for different users within a data base that would be included in the master data 
base for design and engineering information access through the front-end expert system. 

The CAD/CAM system should be designed to help automate the product development 
process. It should be used through the full design cycle, from initial product design, 
modeling and drafting to factory floor layout, numerical control (NC) programming and 
robotic simulation and programming. An especially important feature that a CAD/CAM 
system should have in order to design products for automation and robotics is extensive 
solids modeling capabilities. The cost of CAD/CAM systems are dependent on the number 
of users, and therefore stations, which are needed in the design phase. The system could 
run from the local mainframe as did the DFM/DFA software or on another computer at a 
sight where design is being done. The cost of CAD/CAM systems is justified in that 
design for automation is extremely difficult without them and their proven contributions. 
Before a design is implemented on the CAD/CAM system, it should undergo the 
DFM/DFA analyses to achieve the maximum cost benefit 

Another tool in the CAD area is a structural analysis program to aid in building, displaying 
and viewing complex finite element models, finite element analysis and solving, system 
dynamics analysis, and assembling and analyzing objects. This software could also be run 
from the computer designated for design purposes and be accessed through the front-end 
expert system. 


2.2 REQUIREMENTS ANALYSES 


LRB general design information would be incorporated into the master data base both 
before and during the design process. Drawing "trees" as referred to in Figure 1.3-3 
would allow traceability from smaller parts to larger parts of the LRB. This structure could 
be of further help in examining parts for requirements and government specifications 
because its tree structure allows easy traceability. Comparisons to determine compliance 
would be made by the expert system against the specifications and requirements which 
have been incorporated in the data base. Inherent checks would not allow a part which has 
not been found to be in compliance with all checks to become a part of a larger system. 
The expert system could log in change requests and show the effect that the change would 
have on areas such as cost and scheduling effects on the MRP n system. It also could 
determine if the change would be in conflict with any requirement or specification. This 
capability would insure that time is not wasted in examining unallowable configurations. 

2.3 DESIGN DOCUMENTATION 

All LRB design documentation, such as verification forms and checklists, notices of design 
decisions and changes, would be entered into the computer, thus alleviating much of the 
paperwork and those workers associated with it. Request and approval for change records 
on the computer would be a portion of these steps that would relieve much paperwork. 

2.4 MANAGEMENT 

As before mentioned, much information is available from the front-end expert system for 
General Dynamics, NASA, and others needing information. CAD/CAM drawings, 
requirements and change checklists, and design status for a given part are all pieces of 
inf ormation which allow management to make timely and accurate decisions which would 
affect not only design scheduling, but also scheduling for manufacturing activities being 
handled by the MRP II system, and test and flight operations readiness scheduling. The 
expert system could provide many methods of presenting requested information. 
Commands would be simple and processed immediately if possible. 



2.4.1 SCHEDULING 


A top-level scheduling capability would be available for designated individuals through the 
front-end expert system. This scheduler would set scheduling for design and could 
provide input to the MRP II scheduler. The input to the MRP II schedule would enable the 
scheduling ability within the MRP II package to begin. 

2.4.2 INFORMATION CONTROL 

A "checklist" of steps would be required in order to determine if a given LRB part has been 
designed to meet all specifications and requirements. This checklist may be queried at any 
time to determine how the design is progressing. Request for change would also generate 
a series of steps for making the actual changes. These would be entered into the data base 
as they were incorporated. A list of all changes which had been made to a given system 
would be available on request. 



SECTION 3 
PRODUCTION 


A Manufacturing Resource Planning (MRP II) system is a beneficial strategy for 
automation of LRB production. MRP II is involved in indirect and direct support labor, 
material cost, and overhead cost. These areas comprise approximately 83% of total 
recurring cost, and an MRP II system can reduce costs in each of these areas. A good 
MRP II system can provide for a virtually paperless factory. This type factory has already 
begun to show that 70%-80% of paperwork can be eliminated, thereby allowing end-users 
to do faster and better quality work in their functional roles of production support, problem 
assessment, and decision making. 

MRP II systems are common and therefore the technological risk is very low for them. 
USBI has an automated SRB processing system and General Dynamics has a paperless 
cruise missile assembly line. General Dynamics has several such systems which could 
possibly be accessed for use on the LRB, but until more is known about the LRB design it 
would be difficult to identify a specific MRP II system for this program. 

What is needed within an MRP II package is the ability to conform with various 
government regulations as well as the build-to-requirement and actual job costing features 
of aerospace cost distribution. A full multilevel pegging ability is needed to contract with a 
project number, contract identifier, and accounting charge via Work Breakdown Structure 
(WBS) and Manufacturing Breakdown Structure (MBS). Traceability should be 
maintained by contract, task, subtask, part, lot/serial number and family. The ability for 
accumulating costs both incrementally and cumulatively by project and by order should also 
be included. These features are available on several MRP II systems. 

The MRP II system would provide for master production scheduling, bill of materials, 
inventory control, materials management system, material requirements planning, shop 
floor control, purchasing management, cost management, and customer order entry. These 
capabilities will be discussed in sections 3.1 through 3.4 along with information on how 
the MRP II system could augment documentation and management activities. 



3.1 AUTOMATED MANUFACTURING 


Automated manufacturing begins with a good MRP II system. The system should be 
closed-loop and alleviate problems incurred when attempting such activities as updating 
changes to the data base in real time, interrelating information between different 
departments, and communicating information internally between different departments. 

Since current estimates of LRB production rates appear to be relatively low, total 
automation would probably not be an option due to cost considerations. Hands-on labor is 
estimated to be only 7% to 12% of total recurring cost, so it is logical to assume that a 
great deal of money should not be spent on elaborate robotic and automated systems when 
only 7%to 12% of the cost is to be potentially affected. It would be best to automate 
procedures done only on a regular basis or those where the increased quality/safety can 
justify the cost. Use of machines or robots which do odd and rarely performed tasks 
should be avoided. Repetitive tasks are good candidates for automation because these are 
tasks which humans tend to make mistakes at while doing for long periods of time. 

In a number of cases, automation requires that the MRP II portion of the master data base 
communicate with the portion containing design parameters. This could be achieved 
through low level interfaces between these two portions of the data base. 

Two areas where automation is justified from a quality standpoint are engine and tank 
welding. Robotic welding is much more accurate than human welding and produces 
parameters which are important in that they can serve as proof of the integrity of the weld 
and thereby possibly alleviate some amount of inspection. Robotic welding is especially 
applicable to engine welds involving the fuel prebumer, main combustion chamber, and the 
main injector, but it is estimated that as much as 80% of all engine welds could be done by 
a robot. 

Another specific area in which robotics are extremely effective is automated storage and 
retrieval of needed tools; but an Automated Storage and Retrieval System (AS/RS) works 
best when it is busy most of the time and would only be implemented if this were the case. 
Automated Guided Vehicle Systems (AGVS) for waste control, work-in-progress, and tool 
delivery is another technology which would be highly efficient if it could be justified by 



cost savings. This is also the case with power clamping and automated load/unload of 
machine tools. 

With all of the above mentioned technologies, the tendency to create "islands of 
automation," where different tasks are automated but not integrated, is inherent. This 
should be avoided because it negates the increases in productivity these types of systems 
are intended to provide. A major problem of creating a central control for these different 
types of automation, which in this case would be the master data base through the use of 
the MRP II system, is the interfacing of the robots/hard automation with the central system. 
In the case of robotic engine welds, the computer controlling the robot would have to 
communicate with the master data base for engine design information and the MRP II 
system would have to know the proper time to activate the welding system. Specific 
software for this activity would have to be developed. The added complication of 
incorporating these technologies means increased cost and technological risk factors, but 
they can supply increased quality with verification, alleviating some inspection. In some 
cases, quality improvements can offset implementation costs. With robotic welding this 
holds true, but the low production rate is a significant factor with regards to the other 
technologies. Substantial proof of increased quality and minimization of scrap/rework 
should be given before implementing an expensive technology when production rates 
cannot justify them from a cost standpoint 

3.2 AUTOMATED INTEGRATED LOGISTICS SUPPORT (ILS) 

The MRP II system for LRB would provide for inventory control by processing material 
movement transactions with an on-line real-time updating system. This allows 
instantaneous access to part status information. The MRP II system would also support 
serialized part identification and standard two-step cycle counting to support inventory 
control and accuracy. A materials management system would provide on-line support for 
productivity improvements in the warehouse, in work-in-progress and in material delivery. 
To help with accounting and reporting, this system would relieve inventory at 
order/schedule release or at order/assembly completion. Material could be issued as units, 
in kits or in bulk and could be delivered to a cell or a particular workstation. Net change 
and regenerative Material Requirements Planning (MRP) would be provided by the MRP II 
system. The net-change system identifies changes in product structure and inventory status 
immediately and replans MRP daily. Only the affected parts would be expanded and netted 
to create a new material plan. A regenerative option would support periodic recreation of 



the material plan. An on-line purchasing system would follow the full scope of a material 
requirement from the time it became a purchase requisition through the release and printing 
of the purchase order and the receipt, inspection, and storage of goods. Orders could be 
handled on-line, and information such as where to ship, terms of agreement, and order 
acknowledgement would also be available. This order-entry capability might be covered by 
contract specification rather than an order entry sub-system because of low volume 
production. 

3.3 DOCUMENTATION CONTROL 

Control of acceptance documentation pertaining to the newly manufactured LRB would be 
an important task. The pre-designed "checklist(s)” would reside in the master data base for 
access during system verification procedures. The flight certification forms would also 
reside in the master data base for use when verification procedures have been completed. 
Complete verification and certification tracking would also be available. 

\ 

3.3.1 SYSTEM VERIFICATION 

In verifying the LRB system, customer requirements are the main driver in determining 
what automated technologies would or would not be allowed. With the LRB program, 
many automated production technologies produce parameters through in-process control 
that could alleviate some of either government or General Dynamics verification activities. 
Since there would be different types of verification associated with the different LRB 
systems, it would be difficult to identify which systems could or could not be automated. 
Vision systems using computers to acquire images from remote video cameras, perform 
analysis on the image and transmit information to other systems based on the analysis 
would be possible candidates for automated inspection if they are determined to be 
acceptable by the government. Unless this comes about and considering low production 
rates, it would not be cost effective to implement such a system for General Dynamics use 
only. 

3.3.2 FLIGHT CERTIFICATION 

Whatever means is decided upon for verification of a particular part or system, there would 
be formal documentation associated with its approval. Pre-designated forms should reside 
in the master data base and be available at inspection time. Instead of a signature of the 



person approving the inspection, the inspector could have a badge with a specific bar code 
which could be read into the computer when approval was given. This would alleviate 
much paper work and also enhance security in cases where important papers might be left 
lying around. Checklists for verification would reside in the master data base, and no 
system would be totally verified until all of its subsystems had made it through the 
verification checklist. Traceability of this list for any given system would be available upon 
request through the front-end expert system. 

3.4 MANAGEMENT 

By accessing the MRP n system through the front-end expert system, management would 
have information to make basic decisions and have them implemented in near real-time. 
The MRP II system would augment the ability to do this in some cases by simulating the 
effect of a particular change on manufacturing as a whole. Reports and information on 
various topics would be available on request. Monitoring of processes, centralized control 
and timely problem assessment are all made possible through the use of the MRP II 
system. Security would be enhanced because information would be stored in the computer 
and not on paper where it could possibly be lost. Access, both remote and local, would be 
tightly controlled through the use of passwords. 

3.4.1 SCHEDULING/PLANNING 

The master production schedule would be in terms of product configurations for specified 
quantities with specific due dates. It would work with material requirements planning 
subsystem of the MRP n and order entry subsystem for demand to become the basis for all 
other schedules. The master schedule is what drives the material requirements planning. 

The production plan would be stored in the MRP n section of the master data base. This 
plan would be in terms of contract requirements or production philosophy. The production 
forecast would be the result of expanding and posting the high-level production plan to 
intermediate planning items and to real (master scheduled) items. The manual forecast 
would be available for the "master- scheduler" to input his ideas into the planning process. 
An on-line simulation would analyze the effects that certain variables would have on the 
plan. 



3.4.2 INFORMATION CONTROL 


In the area of shop floor control, the MRP II system would have work center routings to 
provide on-line maintenance of work center and routing information. Each assembly might 
have alternate routings. Resources could be assigned to an operation to measure capacity 
requirements over and above machine and labor requirements. Another capability in the 
area of shop floor control would be job progress reporting. This would provide capacity 
planning and schedule work orders for manufacturing. The critical ratio technique would 
be used to help job prioritizing and loading achieve maximum product utilization. 
Input/Output queue control, split orders, and variance reporting would be supported, as 
would the ability to provide contract/work order tracking by identifying parent/child 
relationships on split orders. 

The bill of materials MRP II subsystem would provide basic MRP planning parameters, 
including those which the user has defined. All part master maintenance transactions 
would be on line and segregated by functional area for convenience. A material catalog 
would provide extensive part number cross referencing capability. Multiple bills of 
material would be available, and all bills of material would be maintained using an on-line 
work file to ensure security and efficiency prior to final update. 

In the area of cost management, the MRP II system would use standard cost accounting to 
compare established standard costs with actual performance. A costed bill of materials 
would be developed incorporating incremental and cumulative cost roll-up. Standard 
versus actual variances would be reported against direct labor, direct material, and overhead 
at various levels. Direct costing would be possible through the segregation of costs into 
fixed and variable classifications. Inventory adjustments, historical cost inquiry, and 
responsibility accounting reports would also be available. 

The MRP II system would provide an extensive document tracking utility which would be 
available for use in monitoring various approval levels and departmental checkpoints. 
Visibility of document status and departmental queues would provide timely information 
processing. Request for Offer (RFO) and vendor performance tracking would also be 
available. 


3.4.3 LABOR CONTROL 


The resource requirements planning subsystem of the MRP II system would check the 
production plan for medium- to long-range capital, capacity, and labor needs for the 
production effort. Gross units of measure such as direct labor hours required, test hours 
required, and number of liquid rocket boosters produced would be used by the MRP II 
system to come up with a proposed production plan. This plan could be analyzed by an on 
line simulation to determine required resources before committing material and labor 
dollars. 



SECTION 4 

GROUND OPERATIONS 


Historical data shows that approximately 60 percent of the STS support manpower at KSC 
is involved in processing documentation. The cost for each page is approximately $1,000. 
This volume of paper degrades the quality of data and increases the chance for error in the 
analysis and decision making processes. Massive documentation requirements, 
inaccessibility of data, lack of real-time data, non-centralized operations and management, 
lack of configuration control, and approval/quality control/problem assessment are some of 
the major cost drivers. The LRB master data base would remove many of these cost 
drivers for the LRB system, helping to reduce overall STS costs significantly. Access to 
the system would be given to all personnel needing it, with security maintained through use 
of passwords. 

The primary LRB ground operations functions - system test and checkout, inspection, 
vehicle assembly, and pre-launch operations (fueling, ordnance arming, etc.) - are all time 
and manpower intensive operations. Automation of these tasks would reduce processing 
time, minimi ze the critical path, and improve the overall safety and reliability of ground 
operations. 

4.1 AUTOMATED TEST AND CHECKOUT 

Until more is known about LRB design, many automated test and checkout procedures are 
difficult to identify, and the cost of developing many new technologies for the LRB might 
not be justified because of low launch rates. Vision systems are possible candidates for 
automated checkout if they are determined to be acceptable by the government. At 
sufficient launch rates, implementation of such a system would be cost effective. 

An optical leak detection system for liquid engine processing identified in an Air Force 
Rocket Propulsion Laboratory study offers the potential for automating engine leak checks. 
This could provide significant benefits because of the frequency of these checks and the 
need to verify them. Such a leak detection system could provide pertinent data for the 



master data base, while insuring the integrity of the engine and removing the need for the 
manpower to perform this task. 

An established technology in missile, air transport, and space systems which all LRB 
avionics would contain is the Built-In-Test (BIT). These systems would verify the 
integrity of the avionics system and identify any problem areas. The avionics would 
interface with the master data base to provide status and statistical data. Electronic power 
profile tests, pressurization system checks, and environmental control system checks are all 
candidates for automation dependent on further design information and cost justification. 
Automated fueling as demonstrated by the ET would be an automated pad operation for the 
LRB that would improve safety. 

4.2 AUTOMATED INTEGRATED LOGISTICS SUPPORT (ILS) 

The portion of the MRP II system used for ILS activities in the production environment 
could also be used in the ground operations environment. Again, the main interface would 
be to access the MRP II system through the front-end expert system. The same capabilities 
existing in the production environment automated ILS subsystem of the MRP II system 
also exist here. 

4.3 DOCUMENTATION CONTROL 

Since documentation costs are a major cost and efficiency driver in the ground operations 
tasks of inspection and assembly, automated information processing for these tasks is 
important. As with manufacturing, the pre-designed checklists for these tasks would reside 
in the master data base for access during system verification procedures. The flight 
certification forms would also reside in the master data base for use when verification 
procedures have been completed. Complete verification and certification tracking would 
also be available. Development of this ability within the front-end expert system is 
justified from a cost standpoint because use of the same ability in manufacturing would 
help defray investment requirements. 

t 

4.3.1 SYSTEM VERIFICATION 


In verifying the LRB system, customer requirements are the main driver in determining 
what automated technologies would or would not be allowed. Automated checkout and/or 



the parameters it produces could eliminate or alleviate some of either government or 
General Dynamics verification activities. There would be different types of verification 
associated with the different LRB systems. It would take substantial effort to identify all 
the different systems and which could or could not be automated. 

4.3.2 FLIGHT CERTIFICATION 

Whatever means are decided upon for verification of a particular part or system, there is 
formal documentation associated with its approval. These pre-designated forms should 
reside in the master data base and be available at inspection time. Instead of a signature of 
the person approving the inspection, the inspector could have a badge with a specific bar 
code which could be read into the computer when approval was given or a specific 
password would identify the inspector. This would alleviate much paper work and also 
enhance security in cases where important papers might be left lying around. Checklists 
for verification would reside in the master data base, and no system would be totally 
verified until all of its subsystems have made it through the verification checklist. 
Traceability of this list for any given system would be available upon request through the 
front-end expert system. 

4.4 MANAGEMENT 

Since non-centralized operations and management is a major cost driver, the ability which 
the front-end expert system would have to provide management with information regarding 
design, production, and operations is invaluable. The system would handle requests for 
detailed information which would affect decision making, problem assessment and other 
management activities. Decisions could be implemented in near real time and "the big 
picture" of the program would be available. As each decision is implemented a record 
would be made, providing traceability of decisions. "What if' capability could be provided 
as a tool for assessing effects of a given decision. Reports and information on various 
topics would be available upon request. 

4.4.1 SCHEDULING/PLANNING 

Information from the master data base, such as design and production schedules, would 
allow scheduling for ground operations activities even in early stages of the program. 



Scheduling would be provided by either the top-level scheduler or the MRP II scheduler 
with its wide range of scheduling abilities. 

4.4.2 INFORMATION CONTROL 

Status of LRB checkout, verification, certification, assembly and pre-launch operations 
would be available upon request to the master data base from the expert system. Checklists 
for the above procedures would be pre-entered into the data base at an early stage as 
possible in the LRB program and verifying these procedures would be done as much as 
allowable on the computer. This would provide the needed control of information and 
tracking ability. 

4.4.3 LABOR CONTROL 

Abilities in the area of labor control for ground operations would come from accessing the 
capabilities for this within the MRP II system. 



SECTION 5 

FLIGHT OPERATIONS 


The following is a proposed system for flight operations diagnostics. An operational 
information interface to the master data base would be provided by the front-end expert 
system. This interface would reflect design intent, systems functionality, general design 
information, and operational procedures information. It would interface to an intelligent 
console during an LRB flight. Access to the near-real time data base, decommutation, and 
he master data base would be needed in order for the console operations to provide such 
output as seen in Figure 5-1. 



FUNCTIONALITY: 


- DISPLAY REAL-TIME DATA 

NEAR REAL-TIME 


(NRT) DATA BASE 

- IDENTIFY MALFUNCTIONS 

(SELECTED) 




- PLOT TRENDS 

REAL-TIME 

- DISPLAY NRT HISTORIES 

TELEMETRY 


(DECOMM. EQUIP.) 

- "ON-DEMAND" DISPLAY 


AUTOMATED SERVICES (EXPERT SYSTEM): 

MASTER DATA 

- DETECTION OF MALFUNCTION 

BASE 



- FAULT ISOLATION 


- CORRECTIVE PROCEDURE SUGGESTION 


- OPERATIONAL CONSEQUENCES 


Figure 5-1. Console Operations 



The above output would require an "intelligent" console, where a separate expert system 
would analyze data from the three sources mentioned. Figure 5-2 shows an example of 
console operation. 


PROVIDED BY TELEMETRY PROCESSOR 



Figure 5-2 Example of Console Operations 


Using drawings, diagrams, and other information from the master data base, the console 
display could be very graphic with problem areas highlighted. The user would be able to 
define objects or change definitions in real time. The console expert system would readjust 
the parameters mentioned in Figure 5-2 each time a decision, such as a design decision, 
affecting one of them occurs. This is called knowledge synthesis, and the technology to do 
this is only now emerging. Because of its high technological risk at this point, it would be 
better to "hard-code" the affected parameters into the system when a change would be 
made. The ability to perform the analysis would then exist without the technological risk. 
The above information would be invaluable in a crisis situation, and provide quick and 
accurate information for correcting any problem. This ability would justify the cost of the 
console and the console expert system. 








SECTION 6 
SYSTEM DEFINITION 


The proposed LRB automated management and operations system would integrate the 
program from design to flight operations. The power of the system to provide the 
information for this would come not only from the great amount of information residing in 
the master data base, but also from the ability of the front-end expert system to present the 
information there in real-time and pertinent form. Data bases are common and powerful in 
themselves, but the expert system would provide centralized control over the program 
along with system relationship and tracking information in all areas. It also is the means 
for incorporating the CIM philosophy. The expert system would integrate the functions of 
the design, MRP II and operations hardware and software. 

6.1 SUMMARY OF SYSTEM REQUIREMENTS 

The major software needed to complete the system is as follows: 

Data base software for master data base 
Front-end expert system software 
DFM/DFA analyses software 

CAD/CAM and CAE (Computer Aided Engineering) software 
MRP II software 

Software for Robotic Welding (including interface) 

Software for Optical Engine Leak Check 
Operations Expert System Software 
Network Software 

Software interfaces for other automated 
procedures 




The major hardware needed to complete the system is as follows: 


Local (front- end) mainframe computer 
Computers for design purposes 
Computers for MRP II work 
Robot for engine welding 
Visual Systems for Optical Leak Check 
BIT hardware 

If production and launch rates can justify usage of the following technologies, hardware 
and software would be needed to support them. 

AS/RS 
AG VS 

Power clamp and automated load/unload 
Electronic power profile tests 
Pressurization system checks 
Environmental Control System checks 
Automated fueling 

6.2 SCHEDULING AND COST 

The time frame for developing the expert system would be from eighteen months to 2 
years. This time frame is heavily dependent on the availability of the experts in all of the 
program phases for routine information to help in developing user interfaces to the data 
base. The availability of resources for optical leak check systems, robotic systems and 
automated fueling systems would also have to be investigated. Interfaces would also 
require development and test time. Most of the other technologies are available at this time. 
Time for integrating and testing all parts of the system is needed. 


Preliminary costs for major hardware and software considerations are as follows 


SOFTWARE: 

Data base software for master data base 100K 

Front-end expert system software 

(mostly software development cost) 2000K 

DFM/DFA analyses software IK 

CAD/CAM and CAE 

(Computer Aided Engineering) software 136K 

MRP II software * 

Software for Robotic Welding (including interface) TBD 

Software for Optical Engine Leak Check TBD 

Operations Expert System Software TBD 

Network Software TBD 

Software interfaces for other automated 

procedures TBD 

HARDWARE: 

Local (front- end) mainframe computer 

(includes some operating software) 250K 

Computers for design purposes TBD 

Computers for MRP II work TBD 

Robot for engine/tank welding TBD 

Visual Systems for Optical Leak Check TBD 

BIT hardware TBD 


* Possible use of existing General Dynamics and NASA resources 
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ENVIRONMENTAL ANALYSIS 




NOTE: 

THIS APPENDIX CONTAINS DATA REQUIREMENT NO.7, 




UPDATE REPORT 


ENVIRONMENTAL ANALYSIS 
LIQUID ROCKET BOOSTER STUDY 


July 12, 1988 

Bar indicates changes or additions from last revision dated 

February 12, 1988 



ENVIRONMENTAL ANALYSIS OUTLINE 


I. Summary and Conclusions 

The existing STS launch vehicle includes Solid Rocket 
Boosters (SRBs) which produce environmental impacts 
relative to noise, air quality, surface water and 
biological systems. Major impacts are associated with the 
ground cloud. 

As an alternative to the SRBs, NASA is considering whether 
to introduce Liquid Rocket Boosters (LRB) . This 
environmental analysis discusses the impacts of four 
potential LRB configurations relative to the existing SRB 
configuration. The LRBs and associated impacts are 
categorized by oxidizer/ fuel combinations for the purpose 
of this analysis. 

Final report will be updated to include recommendations 
regarding necessity for an environmental impact statement. 


o L0 2 /LH 2 impacts. 


Reduced air quality impacts. 


Reduced toxic cloud impact. 


Reduced stratospheric ozone impacts. 


Possible reduced noise impacts (thrust reduction) . 


Reduced water impact. 
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Facility construction impacts. 

- Increased probability of fuel handling accidents 
L0 2 / ch 4 impacts . 

Reduced air quality impacts (>L0 2 /LH 2 ) 

- Reduced toxic cloud impact. 

Reduced stratospheric ozone impacts (> L0 2 /LH 2 ) . 

- Possible reduced noise impacts (thrust reduction) 
(> L0 2 /LH 2 ) . 

- Reduced water impact. 

Facility construction impacts. 

Increased potential for fuel handling accidents. 
L0 2 /RP1 impacts. 

Reduced air quality impacts (> L0 2 /LH 2 ) . 

Reduced toxic cloud impact. 
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Reduced stratospheric ozone impacts (> LO2/LH2) • 


Possible reduced noise impacts (thrust reduction) 

(> LO2/LH2) • 


Reduced water impact (> L 0 2 /LH 2 ) • 


Facility construction impacts. 


Increased potential for fuel spillage. 


(Need discussion of areas of controversy.) 


(Need conclusion on heed for EIS.) 
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II. Purpose and Need 
o Introduction 


NASA will decide if it will proceed with advan< 
Solid Rocket Boosters (SRB) for the Sp; 
Transportation System (STS) or plan to introdi 
Liquid Rocket Boosters (LRB) . 


SRBs appear to be advantageous due to a) simplici 
and b) compatibility with existing ground suppc 
facilities. 


LRB concepts are expected to be advantageous due 
a) superior performance b) safety, and 
environmental impacts. 


This document is an environmental analysis 
impacts associated with using LRBs on the S 
program as compared to using existing SRBs. 


o Relevance to national environmental policies. 


Relevance to national environmental objectives. 


The National Environmental Protection Act (NEPi 
sets forth the following as broad nation; 
environmental objectives (sec. 101 [b]): 


1) Fulfill the responsibilities of each generatic 
as trustee of the environment for futui 
generations ; 


ORIGINAL 

WJOI? 


^GE is 

Quality 
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2) Assure, for all Americans, safe, healthful, 
productive, and aesthetically and culturally 
pleasing surroundings; 


3) Attain the widest range of beneficial uses of 
the environment, without degradation, risk to 
health or safety, or other undesirable or 
unintended consequences ; 


4) Preserve important historic, cultural, and 
natural aspects of our national heritage, and 
maintain, wherever possible, an environment 
which supports diversity, and variety of 
choice; 


5) Achieve a balance between population and 
resource use which will permit high standards 
of living and a wide sharing of life's 
amenities; and 


6) Enhance the quality of renewable resources and 
approach the maximum attainable recycling of 
depletable resources. 


Reduced environmental impacts associated with 
proposed systems. 
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HI- Descrip tion of Proposed Action and Alternatives 


o Introduction 

As an alternative to existing Solid Rocket Boost' 
(SRB) for the STS program. Liquid Rocket Boosters (L.‘ 
are being considered. This section describes 
different LRB configurations being considered. 


The four alternatives are as follows: 

1) LRB1: New pump-fed engine: (L0 2 /RP1) . 


2) LRB2 : New pump-fed engine: (L0 2 /CH 4 j 


3) LRB3 : New pump-fed engine: (LQ 2 /LH 2 ) 


4) LRB4 : New pressure-fed engine: (L0 2 /RP1) . 

(See Table 1.) 


While there are four alternatives being considered, 
they can be grouped into three alternatives by fu 
type for the purpose of evaluating environment 
effects. This results in a consideration of a liqu 
oxygen/RPl alternative, a liquid oxygen/ liquid metha' 
alternative and a liquid oxygen/ liquid hydrog* 
alternative. 

For a detailed description of the affected 'environmen 
refer to References 1 and 2. 

Reference 1: Environmental Resources Document 

NASA, JF Kennedy Space Center, KSC-DF-3080, No' 
1986. 


Reference 2 : Environmental Impact Statement. Snac 

Shuttle Program . NASA TM-82278, April 1978. 
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TABLE 1 


PERFORMANCE DATA - LRB ALTERNATIVES AND EXISTING SRB 



LRB1 

LRB 2 

LRB 3 

LRB 4 


lo 2 /rpi 

lo 2 /ch 4 

lo 2 /lh 2 

lo 2 /rpi 


New Engine 

New Engine 

New Engine 

New Engine 


Pump Fed 

Pump- fed 

Pump- fed 

Pressure- 

fed 

Booster 

Length (ft) 

163 

162 

188 

175 

Diameter (ft) 

13.2 

13.1 

15.3 

14.2 

Total 

Propellant 

1,045,000 

794,000 

567,000 

1,126,000 

(lbs) 

GLOW (lbs) 

4,128,707 

3,642,000 

3,226,855 

4,404,468 


SRB 

Existing 

Solid 

Booster 

150 

12.2 

1 , 110,000 

4,500,000 
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IV . Environmental Impacts 


estibliShSrf h v - a J® discussed relative to a baseline 

talfZ 1 Pn,v a f V . enstlng space shuttle operations using 
?n^i d t asters. The purposed action consists of 

rrt U T^Tr alte 5 natlVes described previously using LO-j/RP, 

L0 2 /RP 4 L -° 2/LH 2 fuel _ s; , t 1 ) a new pump-fed engine 2 using 

LC^/RP-l (2) a new pump-fed engine using L0 2 /CH 4 , (3) a new 
pump-fed engine using L0 2 /LH 2 , and (4) 2 k pressure-?ed 
system using L0 2 /RP1. An action alternative will consist 
S f 1 maintaining shuttle operations with existing Solid 
Rocket Boosters. y iia 


LQ^/LH 2 Fuels 


o Ground Level Air Pollution Effects. 


o 


1) Primary products of combustion (H 2 0) . 

2) After cloud burning will result in 
formation of NOjj (acid rain?) . 

3) No significant particulate/acid formation. 
Stratospheric Ozone Effects. 


limited 


1) 


Elimination of CL 2 and Al 2 03 will decrease effect 
on ozone depletion. 


2) Ground operations using chloro-fluorocarbons/ 
freons. (is there an increase here?) 
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o Noise 


1) Blast overpressures - required thrust levels appear 
to be reduced over existing system. May result in 
reduced noise levels associated with launch, if not 
offset by increased gas velocities. 


2) Sonic booms - slight effect anticipated due to size 
and weight changes. 


o Water Pollution 


1) Significant reduction in impact of launch. 


o Biological Impacts 


1) Blast overpressures expected to be reduced from 
present system. Impact on flora/ fauna associated 
with blast may be slightly modified. 


2) Elimination of acid cloud and particulates will 
reduce impacts. 


o Environmental Impacts from Potential Accidents. 


1) Fuel spills. 


2) Fires and radiation. 


3) Overpressure effects. 
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4) Explosive risks due to handling of increa 
amounts of LH 2 and L0 2 . 


LOo/CH^t Fuels 


o Ground Level Air Pollution Effects 


1) Primary products of combustion (C0 2 , H 2 0, N 2 ) . 

2) After cloud burning will result in limit 
formation of N0 X/ CO, etc. 

3) No significant particulate/ acid formation, 
o Stratospheric Ozone Effects 


1) Elimination of CL 2 and A1 2 0 2 will decrease effe< 
on ozone depletion. 


2) Ground operations using chloro—f luorocarbons 
freons. (Is there an increase here?) 


o Noise 


1) Blast overpressures - required thrust levels appea 
to be reduced over existing system. May result i 
reduced noise levels associated with launch, if no 
offset by increased gas velocities. 
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o 


2) Sonic booms - slight effect anticipated due to size 
and weight changes. 


Water Pollution 


1) Significant reduction in impact of launch. 


o Biological Impacts 


1) Blast overpressures expected to be reduced from 
present system. Impact on flora/fauna associated 
with blast may be slightly modified. 


2) Elimination of acid cloud and particulates will 
reduce impacts. 


o Environmental Impacts from Potential Accidents. 


1) Fuel spills. 


2) Fires and radiation. 


3) Overpressure effects. 


4) Explosive risks due to handling of increased 
amounts of L0 2 and handling of CH 4 . 
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L0 2 /RP1 Fuels 


o Ground Level Air Pollution Effects 


1) Primary products of combustion are CO, C0 2/ c 

H 2 0. 


2) Decrease in launch ground cloud acid levels sir 
no Cl 2 and A1 2 0 3 in exhaust gases. 


3) After cloud burning will result in limit 
formation of N0 X and S0 X . 


o Stratospheric Ozone Effects 


1) Elimination of Cl 2 and Al 2 0 3 emission will ha 
decreased effect in 03 depletion. 


2) Ground operations using chloro-fluorocarbons/freo; 
(Increased use on engines?) 


o Accoustical Noise 


1) Blast overpressures - required thrust level 
approximately the same as SRBs. Levels will h 
evaluated further as design is better defined. 


2) Sonic booms - no significant changes expected. 
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o Water Pollution 


1) Less deposition of metals and acids into surface 
and ground water. 


o Biological Impacts 


1) Flora - Decrease impact on plant life due to lower 
acid deposition levels. 


2) Fauna - less impact on fish and wildlife due to 
lower toxicity levels of a exhaust clouds. 


3) Blast impacts are expected to be comparable. 


o Environmental Impacts from Potential Accidents. 


1) Fuel spills. 


Hazardous waste impact (RP1) . 


2) Fires and radiation. 
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Construction Impacts 


The use of LRBs for the STS will result in major (in 
case of the use of L0 2 /LH 2 or L0 2 /CH 4 systems) and mi 
(in the case of the use of L0 2 /RP1 systems) modificati 
to VAB assembly platforms. Additionally, varying degr 
of modification or construction will be required to • 
fuel transfer /umbilical systems. Environmental impa< 
associated with these construction efforts must be asses: 
as the design is more definitized. 


No-Action Alternative 

In the event of no action, the STS would use the exist: 
SRM. These impacts are discussed in detail in 
Reference 2 . 


Agencies and Individuals Contacted. 


To complete an environmental analysis, the followi 
agencies will need to be contacted. Addition 
agencies and individuals will be identified during t 
investigation. 


1) Environmental Officer, JF Kennedy Space Cente 
Florida. 


2) Environmental Officer, Vandenberg Air Force Bas> 
California. 


3) Environmental Office, Headquarters Space Divisioi 
Los Angeles, California. 


4) NASA/KSC biomedical office. 
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5) Florida office of Coastal Management, Department of 
Environmental Regulation, Tallahassee, Florida. 


6) Bureau of Air Quality Management, Tallahassee, 
Florida. 


7) US Environmental Protection Agency, Region 4, 
Atlanta, Georgia. 
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SPECIFIC ANALYSIS REQUIRED FOR EA 
Water vapor impact on stratosphere. 

Noise impacts (+) . 

RP1 ground cloud (CO - C0 2 ) . 

N0 2 generation differences L0 2 /LH 2 , L0 2 /RP1, L0 2 /C 

SRB • 

Fuel handling accidents (environmental consequences) . 
Construction impacts. 

Possible increased use of chloro— fluorocarbons j 
cleaning. 
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LRB ENVIRONMENTAL IMPACT INCREMENTS 


Fuel 

Launch 

L0 2 /LH2 

lo 2 /kpi 

LO 2 /CH 4 

Air quality 

- 

- 

- 

Noise 

- 

- 

- 

Water 

- 

- 

- 

Sonic Booms 

- 

- 

- 

Ozone 

- 

- 

- 

Biological 

- 

- 

- 

Construction 

+ 

+ 

+ 

Fuel Handling 
Accidents 

+ 

+ 

+ 


+ Indicates increase with respect to SRB. 
Indicates decrease with respect to SRB. 
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